33.2. Slow TestsEmily and Neo found that as the number of running tests grew, they ran too slowly to give fast-enough feedback after making changes. They waited while the tests ran, which was frustrating. As Neo said, "This is a pain; let's make more changes before we run the tests, so we make faster progress." So they made more changes before checking that they hadn't broken anything. As Emily pointed out, however, "We're spending time debugging instead, which is even more frustrating. It's time to tackle the speed of the tests so we get faster feedback and make quick progress without frustration!" After looking briefly into the cause of the speed problem, Emily and Neo figured that it was owing to the speed of the user interface and of the database. Neo was eager to start making changes. But Emily suggested, "Let's put some print statements in the fixture adapter code to see how frequently different parts of the GUI are used. It's better to know where the performance issues are, rather than guessing." "Hmm, good idea," agreed Neo. "It's no different from understanding and improving any other performance problem"[Fow02b]. They subsequently found that the setup adapter code was executing most frequently. "It's obvious when you think about it," reflected Emily. "It should be straightforward to add setup methods to the API," said Neo. "Yes, let's do that next," replied Emily. |