Software-Ratschläge eines Bugtrackingsystemverkäufers

Standard

Update: Code-Beispiel rausgenommen.

Joel Spolsky hat wieder einmal etwas geschrieben. Sein neuer Blogpost beginnt gut mit dem Wert von Simple Code und geht dann über zu dem üblichen Gejammere, dass Unit-Tests böse sind. Außerdem brauchen Entwickler nicht klug sein, weil blöde Entwickler schön sind, oder so ähnlich. Die Antwort von Robert C. Martin (Uncle Bob) ist viel besser.

Viele Entwickler, die jetzt mit TDD arbeiten, haben vorher auch schon Software geschrieben. Ich erinnere mich nur mit Schaudern daran. Vor vielen Jahren habe auch ich an Projekten mitgearbeitet, wo ohne Unit-Tests gearbeitet wurde. Oft war der Grund, dass mit Technologien gearbeitet wurde, die das Testen erschweren, z.B. VBA. Wenn dann auch noch der Projektdruck dazukommt, entstehen schon mal Word-Makros mit ca. 10.000 Zeilen und seltsamen Kontrollstrukturen. Lesen lässt sich dieser Code dann nicht mehr.

Meistens war ich der Entwickler, der in der Wartungsphase neue Features einbauen musste, bzw. Features ändern musste. Das war selten ein Vergnügen.

Derartigen Code habe ich jedenfalls nicht mehr gesehen, seitdem ich mit TDD arbeite. Natürlich ist die Welt auch mit TDD nicht perfekt, aber der Code ist viel evolvierbarer als der Code, der von Joel Spolskys Isolationsbandentwickler geschrieben wird.

Und ja, es ist wichtig, dass die Software verkauft wird. Aber ich weiß nicht, woher das Märchen vom zusätzlichen Aufwand für Unit-Tests kommt. Ich starte den Debugger meistens nur mehr als Designwerkzeug. Wahrscheinlich ist der Aufwand größer, wenn man die Tests nachher schreibt und noch keine Erfahrung damit hat. Dann verliert man ohnehin den Vorteil von TDD als Design-Tool.

Übrigens, der Entwickler, den Spolsky in seinem Blogpost zitiert, hat anscheinend am Netscape Communicator mitgearbeitet. Wir wissen ja, was daraus geworden ist.

When Is a Test a Unit Test?

Standard

Developers write their tests usually with a unit test framework. Often those tests are slow and unreadable. Almost always the tests communicate with a database, a file system, a web service or other external resources. Developers stop executing the tests regularly and further they stop writing tests entirely, because “unit tests” are so slow and hard to maintain. Michael Feathers has already summarized the criteria for unit tests in September 2005:

“A test is not a unit test if:

  • It talks to the database
  • It communicates across the network
  • It touches the file system
  • It can’t run at the same time as any of your other unit tests
  • You have to do special things to your environment (such as
    editing config files) to run it.

Tests that do these things aren’t bad. Often they are worth
writing, and they can be written in a unit test harness. However,
it is important to be able to separate them from true unit tests so
that we can keep a set of tests that we can run fast whenever we
make our changes.”

Developers often even do not write unit tests! They are writing integration tests instead. Sometimes it takes more than knowing the test attributes of the used unit test framework to write real unit tests!