TDD I Learned… | Brendan Tompkins
I’m a TDD wannabe. I’ve done small tasks using TDD, and I’ve written plenty of tests, but most just get shuffled around, never included in my CI builds, and basically the entire thing is a mess… Perhaps it’s because I’ve been writing code for startups, but most likely it’s because I’ve just not taken the time to learn the right way. I’ve never truly seen the benefits that it can bring. So I saw this class as a great chance to learn from the master.
I’m going to blog about my experiences going through this course. I’ve been through the first two hours, and so far I really like the pace and Roy’s teaching style. Roy is snarky-funny, and so the content is entertaining to boot.
So here are some of the more interesting things that I’ve learned from the course so far…
Difference between Integration Tests and Unit Tests
Although the generally accepted definition of the difference may be up to some debate, Roy’s definition is simple, I like it, and it’s useful for me. Roy says that a unit test is all in memory. It should pass on any new developer’s machine, and is not tied to disk, databases or anything outside of the memory scope of the test. This is important because confidence in your unit tests is paramount. If you cannot trust that a failing test is due to a bug, i.e. if it’s due to some setup on disk, etc. it diminishes the usefulness of your test suite and developers cannot quickly setup to work on a codebase.
Arrange, Act, Assert
The three A’s of unit testing was new to me, and is a pattern for writing tests that Roy introduces:
Each method should group these functional sections, separated by blank lines:
- Arrange all necessary preconditions and inputs.
- Act on the object or method under test.
- Assert that the expected results have occurred.
This approach, by eliminating assert code intermixed with code that sets up or acts upon your objects, reduces smelly tests by separating what is being tested from all the other stuff. See, I need stuff like this to help me fall into a pit of success of testing.
There’s a lot of good stuff in there about creating readable and maintainable tests. Roy also delves into best practices for naming tests, offers some good hints on how to setup Resharper live templates, a good deal of information on why he prefers TestDriven.Net as a test runner (and how to use it to debug methods directly!) including an interesting history lesson on MSFT vs TestDriven.Net’s Jamie Cansdale.
With over nine hours of course total, I’m expecting to learn a lot. Oh, and apparently serial killers practice TDD.