stevewedig
stevewedig

Reputation: 294

Should my unit tests of GUI components contain many more lines than the code under test?

This is a sanity check because I'm finding this to be true in our code. Unlike our functional code, the tests of stateful GUIs have an unfortunate amount of weight due to state setup, combinatorial case analysis, and mocking/faking neighbors/collaborators/listeners/etc. Am I missing something? Thanks for your feedback.

Notes:

New Notes:

Upvotes: 6

Views: 150

Answers (1)

Tomasz Nurkiewicz
Tomasz Nurkiewicz

Reputation: 340973

  1. Avoid code duplication. Common setup code and actions should be extracted
  2. Look for hierarchy. Don't write one huge test scenario. Group common lines together and extract them to a meaningfully named method. Proceed building multi-layered test scenario
  3. Consider better tools. cucumber, FEST assertions, Scala or Groovy as test DSL (even if you don't use them in production code), mockito...

Besides that, the relation between the number of production and test lines of code is irrelevant. I can easily find an example of extremely short piece of code having so many edge cases that it requires dozens of tests.

And a real-life example of SQLite (emphasis mine):

[...] library consists of approximately 81.3 KSLOC of C code. [...] By comparison, the project has 1124 times as much test code and test scripts - 91421.1 KSLOC.

That's right, it's approximately 1100 lines of test code per each line of production code.

Upvotes: 5

Related Questions