Test-driven User Interface



  • I am working with a special-purpose database. It has no SQL interface, so if you wan to use it from your application, you have to build the query with objects, with code like query.addFilter(new AttributeFilter("value", "GT", "1.0")), which can be pretty annoying. There is also a GUI where you can enter a query string, which is basically a string representation of the query objects. It requires a lot of brackets and quotes and isn't very robust, but it gets the job done.

    Once, I added a feature to this DB and wanted to add some automated tests for it, so I looked into the test suite. I found that many tests use the same type of query string that you can use in the GUI, and that they all extend a common TestCase base class where the string is parsed and to create the query objects. Because the test framework is a hole WTF by itself and I couldn't get my test to run, I added some logging statements to the TestCase base class, to see if it even tries to run my test.

    At this point, I got interrupted by a coworker who had some problems. So we opened up the GUI and ran some queries. After that, I noticed that the log was full with my debug stuff. A bit of poking around confirmed:

    Every time you run a query from the GUI, a new TestCase instance is created to parse and execute the Query.

    The real WTF is that this is quite representative for the overall quality of the architecture.



  • I had a hole WTF the other day, but the doctor sorted it out, and now there is no bleeding.



  • So if I understand correctly -- the tests were written first; then the UI was written. Someone said "the unit test architecture has all the wiring up we need, so we just create a new TestCase to execute our query"????



  • And you guys were running on a single code base?



  • @DrPepper said:

    So if I understand correctly -- the tests were written first; then the UI was written. Someone said "the unit test architecture has all the wiring up we need, so we just create a new TestCase to execute our query"????

    Every other explanation I can think of would be even worse, so I hope that's what happened.

    The project is separated into several modules with very tight dependencies, and I doubt there ever was a point in time where the test code was not part of the regular production release.


Log in to reply