Verwendung von TDD in der Praxis

Kommentare

• 

  21. Mai 2010 von raveman

  I just write some functionally using TDD and it was faster than without tests, but it was because i used integration test. I think the more complex thing you implement the harder is to do it using TDD.

  I also did some big functionally using BDD(after code was written) and when i needed to change it I had problem with changing tests. I ended up deleting the tests, because it was too much work to change it. I believe more in Unit Testing than in BDD. However maybe I was testing too much(I tested the whole app using one BDD Test).

  Antworten
• 

  21. Mai 2010 von Andreas Ebbert-Karroum

  Hi raveman,

  that’s a good point you are raising. Of course, if you just have one BDD test for your whole application, you have to adapt that test every time you change the application. Not very desireable. The way BDDs should work is that you express the business rules in a stable, but executable specification. That should not be a test script, which is brittle and probably breaks as soon as you change your implementation. It rather should be a description of the rules. These executable specifications should really only change, when the rules they test are changing.

  The binding of the executable specification to the application, i.e. how the rules are verified, and how the context in which these rules apply is setup, is changing more often, as you work on the code. On the other hand, the keywords or methods for verification and setup can be reused often in the executable specs, so also there the overhead shouldn’t be too big. I should probably blog about that 🙂 Maybe on Tuesday.

  Thanks for your comments, and good that you had good experience with TDD. Regarding the use of integration tests, you might want to watch a presentation of J. B. Rainsberger: „Integration Tests are a Scam“ 😉

  Kind Regards,
  Andreas

  Antworten
• 

  21. Mai 2010 von Travis Calder

  I think it’s important to recognize the focus of TDD. Generally TDD involves mocking and other forms of abstraction, otherwise it’s impossible. With mocking and stubbing introduced, guaranteeing behavior is impossible.

  That’s where BDD and narative-style tests come in, and they are extremely valuable.

  But at the code level, writing code with TDD has a completely different effect. It acts as living documentation of the code that „cannot“ be stale. It allows you to identify, when you refactor or add functionality, what pre-existing assumptions you may have broken so that you can anticipate otherwise-unexpected behaviours.

  Overall I’ve experienced both faster and slower development with TDD. Sometimes a feature is so simple that the TDD is „extra weight“, and sometimes TDD helps me to clarify what I want before I write it. In both cases, though, I find that the long-term maintenance and change costs of the code I’ve test-driven are substantially lower than the „legacy“ code I have to interact with.

  Don’t believe me? Just think about every time, working with untested code, you had to hesitate before making a change because you weren’t sure if it would break things. I work with legacy code every day, that cost becomes large very quickly.

  Antworten
• 

  22. Mai 2010 von raveman

  Thanks for the reponse and insides. I will watch that presentation, however I truly believe that only live(using real servers) integration tests matters.

  For example I had written LDAP library and integration tests that are using real ldap server(I was trying to mocked it, but it was really hard). However when I run my tests Im 100% sure that lib works with chosen ldap server. It has stopped working once, because new version secretly stopped supporting something in ldap language that i had used. Now im happy that i did not mock that server.

  The biggest problem with testing in web is that you are never sure if the code really works. So after writting tests and code you should start server, deploy the app and test it manually(however I do know people that dont do that and just commit the code, i dont have that much self-confidence). its not possible to check if AJAX reRendered the right part of page with right values(and only that matters, it doesnt matter how well code is written if it doesnt work). only live html(selenium, htmlunit, etc.) integration tests on not mocked server can find that error. They dont sound as cool as mocking server, but they give you 100% certainty that code works(that do sound cool).

  Antworten

Kommentieren