CategoryAntiPattern

We have an unfortunate meme going around here.

In the beginning, TestDrivenDevelopment practitioners pushed all logic out of the GuiLayer into a RepresentationLayer, and tested that. If you test the GuiLayer, a window may pop up and block the tests, and you might spend more time learning to get rid of this window than developing. This lead to the informal suggestion that one not test the GuiLayer code.

Before the beginning, many bosses invested in CapturePlayback testing tools. Then they would test the test-free LogicLayer by capturing many scenarios, thru the user interface, and ensure the LogicLayer behaved. This may have caught a few bugs in the logic, but at the expense of setting the user interface in concrete. This lead to the suggestion that one use CP tools sparingly, and that one test logical objects directly.

Unfortunately, many students of TDD now mistake the first suggestion not to test the GUI for the second.

The first reason comes from the lack of a SpikeSolution or ExplorationPhase. The ability to write tests is more important than fulfilling any given UserStory. Adding any new library requires a burn of non-trivial duration to learn to test that library meaningfully. See TestFirstUserInterfaces.

The second reason is a simple case of the rule "Put the test near the testee". When too many layers divide the test's entry points from the tested items, you get more noise than signal in the results.

Omiting the ExplorationPhase is madness. Testing too far from the testee is madness. Testing the GUI is not.

----

UncleBob has an anecdote about a shop with >10,000 tests or something thru the GUI and into the business layer. This set their GUI in stone, unfortunately. But I can't find the post anywhere - it's on the XpMailingList

----

''I am not at all sure I see the problem here. I routinely test through the GUI; I believe that this is important in order to ensure that the application presents itself to the user in a useful way -- which, after all, is the primary goal of development. The tests ''specify'' the GUI, perhaps, but I don't see how they set it in stone: it's quite easy to change any individual test if a change to the GUI seems warranted. So where's the real problem here? --MarnenLaibowKoser, 12 Aug 2013''

There are many shops - including very large, very mature world-leading SiliconValley shops - who say "FunctionalTest" when they mean "thru-the-GUI test". This means they don't have FunctionalTest''''''s, but think they do.

''Why do you say that? From FunctionalTest: "FunctionalTest''''''s are programs or scripts configured to test that packages (groups of clusters of classes) meet external requirements...". It is immaterial how these tests are conducted. If the external requirement is that the application present itself to the user in a certain way, then the way to test that is through the GUI, and that is a FunctionalTest (OK, maybe more of an AcceptanceTest, but I think that's a special case of a FunctionalTest). Again, what's the problem? --MarnenLaibowKoser, 15 Aug 2013''