That is testability, not Test Driven Development!

I applaud efforts to encourage test driven development, however I find myself cringing at the examples being produced by the framework designers we are supposed to look up to. I've noticed this with the buzz around TDD and ASP.Net MVC and now that buzz is transferring to the Entity Framework. I think it is wonderful that these frameworks are designed with testability in mind. However, it is up to the developer to actually employ TDD when composing their applications. There are other ways to test, such as TLD (test last) or just simple TFD (test first) without the extra intricacies of TDD. So enough with TDD and frameworks, just show us the testability! Testability of course being able to test our code that uses your framework, meaning we can isolate your infrastructure from our components.

If you want to demonstrate that for us, just demonstrate it with simple tests of stubs. It’s rather crazy to try to show it through TDD! TDD is a very incremental process that is almost impossible to blog an example about. Anyone who has read Kent Beck's book, yes I said book not blog, knows that by the end he barely produces a handful of tests! This is the very nature of documenting the process, step by step, of using TDD. I guess blog authors just love to get TLAs into their posts, especially TDD, look I did it too! This often leads to confusion about what TDD is and leads many to think it is synonymous with testing.

A very recent example is with the entity framework article “Walkthrough: Test-Driven Development with the Entity Framework 4.0.” This post, from the title, seems to be an example of TDD with EF4. Reading through it, the first test doesn’t get written until step 14! Prior to that a bunch of production code is composed. This is known as TLD (test last). A bunch of unrelated test code is produced before the heart of what they are testing is addressed in step 22. This happens because the author is taking an integration style approach to testing validation from the repository level and not from the class that implements the concern of validation. This leads to all the excess code produced before step 14 and from 15 to 21, not related to the test cases. I can imagine this happened because the author wanted to demonstrate stubbing with a fake repository in EF, which is a good thing to demonstrate, but doesn’t require TDD to demonstrate, SRP of demonstrations please! This post would probably be better named “Walkthrough: Testability with the EF 4.0.” No offense to the author, but please help us readers know what we are getting into, especially if we are learning something new!

The basics of TDD that are missing from this post:

  1. Test list – a list of scenarios that you have yet to write, a simple to do list. As TDD is very involved with one test at a time, this is a scratch pad of future tests.
    1. Items are added as you go
    2. Items are crossed off as they are completed
  2. Red/Green/Refactor workflow
    1. Write test code first
      1. Don’t write unnecessary test code (especially in setup)
        1. Look at the setup method in step 11, we are writing setup without even knowing what our first test case is!
          1. Person – fn,ln,password are never used
          2. Blog – name, url are never used
          3. Post – Created,Posted,Title,PermaUrl (has string concatenation!!!) and Body are never used
        2. Look at the setup in step 14 of AttempteddoublePostedComment
          1. Each comment defines Id, Created, Posted, Body and Title which are never used! Note: Body not being empty would trigger a failure when writing the next test, but you don’t deal with that until you write that test, not when TDDing.
        3. Unnecessary test code decreases maintainability and readability of tests
    2. Get it to compile
      1. Compilation errors are failures
      2. Just enough to get it to pass
    3. Get it to run and fail
      1. Run time failures of expectations
    4. Implement just enough production code to get it to pass under the given scenario
      1. This often means incomplete or incorrect production code, just enough to get it to pass
        1. Why does step 19 implement Attach/Detach methods, why does it implement queryable operations?
        2. Why does step 20 implement GetPersonByEmail, GetPostById? These are smells that we are testing too much at once! This is a unit test smell I will talk about in my next post with testing tips. Some of this is needed because of the integration style testing that is going on in this post, my testing tips will tackle and remove this complexity.
          1. We now have code that isn’t tested in production that likely has needs to be tested. Things like GetPersonById and all the other query/add operations on the BlogRepository!
    5. Refactor
      1. Remove duplication between test and production code, or in production code alone
      2. Perform any other optimizations
    6. Make sure test still passes
    7. Repeat

I hope that this helps clear up some of the confusion that might exist around the differences between testability and TDD. If you want to know more I highly suggest Kent Beck’s book “Test Driven Development: By Example”, it is a great introduction to TDD with fully documented walkthroughs!

See my next blog post where I continue an analysis of this article and offer up some testing tips.

comments powered by Disqus