8 responses so far ↓

• zwetan // Nov 5, 2008 at 12:47 am

  thank you for this great stuff!

  does the slides are available somewhere by any chance ?

• Sork // Nov 6, 2008 at 4:39 am

  Thanks a lot for your talk, it was very informative and insightful.

• Andrew // Nov 30, 2008 at 8:55 pm

  Wonderful talk. More people should have been there!

• Jonathan Allen // Dec 2, 2008 at 10:56 pm

  Why the hell are you complaining about static methods?

  Seriously, is there any difference between:

  Math.Absolute(x)
  x.Absolute()

  No. Look at the assembly, it compiles to the exact same thing. The only difference is that in the second line the parameter happens to before the function name instead of after.

  As for testability, there is zero difference. I cannot think of any reason why I would test one differently than the other.

• Jonathan Allen // Dec 2, 2008 at 11:05 pm

  What about maintainability? You cannot start shuffling everything around just for the sake of testing and completely ignore the complexity it adds.

  Stuff like dependency injection is not free. It adds a significant amount of complexity in terms of the number of possible paths as well as the overall code size.

  Focusing again on the “avoid the new operator” bit. If a class doesn’t know how to construct its own dependencies, then who does?

  Every single location that needs an instance of that class? Do you really want to cut and paste that much code?

  Instead of testing a complete component, with all its dependencies neatly encapsulated, you are just testing a shell. You now have to go back and test everything that uses this component to make sure it is correctly assembling the guts.

• mrclay.org » Archive » Miško Hevery Programming Talks // Jun 29, 2009 at 11:35 am

  [...] Unit Testing [...]

• Osvaldas Grigas // May 31, 2012 at 4:10 am

  Jonathan, if your class under test calls an instance method of its dependency whose implementation is hard-coded, this is just as bad (from testing perspective) as calling a static method of a dependency.

  In both cases, you have no way of isolating the behavior of class under test from the behavior of its dependency, which will only get you so far as integration-testing the interaction between these two classes, but not unit-testing how the single class abides by its contract.

  That is why you’ll want to separate collaborating classes via another contract (e.g. an interface) and delegate the job of wiring concrete implementations to some factory class or a dependency-injection framework.

  To understand exactly why there is so little value in integration tests and so much value in unit tests, I suggest that you watch this talk by J.B. Rainsberger: http://www.infoq.com/presentations/integration-tests-scam

• First experience with TDD and pair programming | Jun Rong's Blog // Dec 16, 2012 at 6:54 pm

  [...] thinking thoroughly about how we should structure our code while writing the test. I watched the Unit Testing video from Misko Hevery, and he emphasizes that the key for doing TDD is to learn how to write clean & testable code. [...]

Leave a Comment