Derik Whittaker : Methodology, TDD

Failing builds, the sound of silence

Derik Whittaker — Wed, 07 Nov 2007 13:00:48 GMT

I'm sure that everyone has heard the riddle 'If a tree falls in a forest and no one is around to hear it, does it make a sound?'. This riddle is all about observation and knowledge of reality.

Well, I have a riddle for software teams following TDD.

'If a build fails and no-one fixes it, did it actually fail?'

Till next time,

Backing in Unit Tests into an existing project

Derik Whittaker — Tue, 09 Oct 2007 12:35:39 GMT

Recently I was asked about backing in unit tests into an existing project. In particular I was asked A) was possible and B) is it worth it. In short my answers to both these are Yes and Yes. However, backing in unit tests is not without its challenges. I thought today I would go express my experiences with doing exactly this and what types of hurdles I ran into.

Start off by only testing new code
When backing in tests, it is very important to accept the fact that a large percentage of your application is going to be untested. Accepting this fact will help you move forward. I would suggest that as you write new code (be it new modules, features or whatever) you write them following the TDD practice. This will be the simplest way to get the ball rolling.

Doing this is also an easy way to get other team members on board with the testing idea. I know from personal experience that when we wanted to started following TDD on a project that was 2 years in, many of the other developers thought it was a waste because we have so much that is untested. They thought it would take too much time/effort to write test for existing code. I agree with this. So only test going forward

Add tests to existing code only when changes are needed
I know I just said above to only test new code, and this is true. However, when you are making changes to existing code test those changes. Again, you don't have to try to test all the existing code, only the path ways you are adding/changing.

If you follow this, over time you will start to build a nice suite of tests that tests not only new code, but some existing code as well.

Mock as much as possible
Mocking is a great tool. I like to mock code that I don't have control over, or when I have no faith the code will work reliably. This is especially important in a project that does not have tests.

An example would be this. Lets say you are adding a new feature to an application that needs to call into some sort of calculation engine. Since this calculation engine is not tested and you have no real faith that it will work reliably, mock it. You should know that given a valid set of inputs you expect to receive a given response. By mocking this you remove all risk of the calculation engine failing thus causing your tests to fail.

*** I can hear you now, you want your test to fail when the calculation engine fails.... No you don't. Unless your test is actually testing the calculation engine, you don't care if it passes or fails. You just need to call it. ***

Take this as a learning experience
Take this time as a way to learn to write good solid tests. This will be of great benefit later in your next project. Also, you will also learn how to write better code that is more acceptable to testing (hum... sounds like another good post). Remember, in order to become good at something you must first be bad at it. But with practice you will become better and you will be a better developer because of it.

Be patient
Testing is painful at first. It is a shift in your development mind set. Be patient, it gets better. This is no different then learning anything else. It will take time, but eventually you will become comfortable with TDD and it will become second nature. You never know, you may end up like me and find it odd when you are NOT writing tests.

I hope this helps.

Till next time,

Why I believe IN and WRITE unit tests

Derik Whittaker — Tue, 02 Oct 2007 00:27:25 GMT

In my last post I think I struck a cord with some people in my post 'Unit tests taking too much time'. My intent was NOT to sound like an elitist Agilist or any else of that nature. My intent was simply to put a post out there about the misperception (in my opinion) about how writing unit tests take too much time.

I thought I would put my 'retort' on why I believe in and write unit tests.

Allows ME to write better code

I believe that when I truly follow TDD practices my code comes out simpler. I have also found, that my code tends to follow YAGNI more so then when I don't follow TDD practices.

Here is an example from my past experience. On a prior project I needed to build a 'search engine' into our app (this was not an actual search engine, more like a hunt path engine). When I first started out writing code I started out by creating all these classes and logic that I thought I would need. After about 3-4 hours of coding I was dead in the water. I was not able to solve my problem in a simple manner and I was frustrated. I decided to take a step back and start over.

This time though I started out by writing test to mimic what I actually needed. I continued to follow the principles of TDD (btw, TDD is more then just about writing tests), within an hour or so I had my solution pretty much good to go. All those classes and methods I THOUGHT I would need I did NOT. I was able to scrap about 50% of the code/classes that I thought I needed. And guess what, now I have a test suit to test my new code.

Allows ME to find more bugs during the development process

It has been my experience that I find more bugs while writing tests. This is due to the fact that I not only follow TDD, but I also do my best to implement the Fail Fast Principle. When I am writing my tests I have the ability to create tests that easily walk though the different pathways of my code (I attempt to hit 100% code coverage as well). If I were not writing tests I would have to do this via the application, and this is much more painful and it less likely that I would actually do it.

By writing my tests and testing my code during the development process I know that I have reduced my bug count significantly.

Makes ME feel more comfortable making changes

This is the beauty of TDD, I am not afraid to make any critical changes to my code because I KNOW that I have tests to verify if I screwed anything up.

Have you ever run across some code that 'you were scared' to change? If you had tests for that code I bet you would a WHOLE LOT LESS scared to make any changes. I know that I am.

A case in point for this is as follows. On a prior project a consultant I was working with needed to make changes to some 'smelly' logic. This just happened to be a week or so before a scheduled release. Beacuse he had NO confidence that the changes he would make would NOT break the application, he convinced the business to NOT make the changes. I bet you a dollar that had there been unit tests he would have been much more willing to make the changes. In this case the fact of NOT having tests may have caused the business to lose out on features it needed.

Improves MY code

Because following TDD practices forces you to write your failing code before your passing code, I tend to implement my intent much cleaner and simpler. I also know that because I am writing tests along the way my code is solid.

Allows ME to better convey intent

I know that tests are not a substitution for quality comments that convey intent, but they sure are the next best thing. It is really nice to be able to point someone towards a suite of tests to 'demo' how to use a component.

A case in point for this is as follows. A few weeks ago at work I wrote an API to allow the querying of some data via our imaging system at work. Turns out that an outside party needed to use this API for integration into on of our 3rd party applications. When he came to me asking for 'how do I use this', I simply emailed him my suite of tests. In this suite I had pretty much any conceivable use for the API. To date the vendor has not asked me how to implement the API.

Allows MY tests to be automated and rerunable

This is a nice side effect of having tests. Because we use both NUnit and CruiseControl I can run my tests on every check in. This is cool because now I (and the team) know if changes I made breaks some other part of the system. I would rather know now then before QA hits it.

The above are simply my opinion, if you don't share the same opinions, let me know.

Till next time,

Fail Fast Principle

Derik Whittaker — Fri, 08 Jun 2007 18:08:00 GMT

I am thinking about posting about different principles/patterns over the next few weeks/months. I have decided to start with Fail Fast. This is something that I think most people over look or plain just don't do. Although the concept of Fail Fast is easy...(read more)

Technical Debt, How we accumulate it, and how we can reduce it

Derik Whittaker — Fri, 25 May 2007 14:03:00 GMT

All software projects will amass some amount of technical debt. This is not a necessarily bad thing; it is just he cost of doing business. As developers the only thing we can do is try to control/limit the amount of technical debt we build up. If you...(read more)

Learning to use Mocks and the power they provide

Derik Whittaker — Wed, 23 May 2007 11:54:00 GMT

Up until a few months ago I had never even attempted to use mocks ( NMock , RhinoMock , etc). Every time I would read about Mocking I thought to myself, this is kinda cool, but seems to be a waste of energy. At the time I saw Mocks as only a way to create...(read more)

Raising Events in NMock 2.0

Derik Whittaker — Tue, 17 Apr 2007 14:42:00 GMT

Just to pass this along. I was needing to raise events in NMock and I came across this post on how to Raise Events in NMock2. This is a good post with clear examples.

Enjoy

Options Wanted: How do I handle my Mocks

Derik Whittaker — Tue, 17 Apr 2007 12:35:00 GMT

I am looking for feedback from the group. I am pretty new to using mocks for my unit tests and I am not sure what the standard approach in the community for usage of mocks in regards to how/where they are stored in your test application.

After refactoring some of my tests to use mocks I quickly noticed that I was littering the same mock creation code in many of the unit tests. So, the first thing I did was create a local helper method inside my test. However, as I continued my refactoring I was started to create the same helper method in many classes. After noticing what I was doing, I knew there had to be a better way to do this.

What I am thinking of doing is creating a ‘Mocks project’ that will only contain static methods that can be called (with and without construction params) to build and return a mock for a given interface. The reason I want separate class for this is because 2 different projects use the same backend, but each have their own test suite.

Does this sound absurd?

Thanks for any insight.