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

Question

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:

• The tests are running in the JVM, everything is a POJO.
• So far we've gotten some simplification by increasing unit size: testing more pieces glued together.

New Notes:

• We're using jUnit and Mockito.

Answer 1

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.