At our company there have been many attempts at doing the tests first and the coding
second, but none of them have been successful. I believe there are several reasons
for this:
-
We always use the same design pattern enforced by our auto-generated code. The
pattern used a hybrid active record/domain pattern which seemed pretty pointless
to test. The focus on keeping our application structure as simple as possible
meant that we lost out on an architecture that would have been more conducive
to testing.
-
Our general approach to put business logic in the UI layer is altogether wrong -
this forces us to not only use extensions to nUnit like nUnitASP to do our testing
but it means one has to do a whole bunch of coding before one can actually start writing
tests. By that point you are so in to it that you might just as well complete
the work. Often people would also code in tons of JavaScript logic which makes
it even more challenging to unit test (we could use a tool like Samie to
do this) .
-
We didn't go with the approach that the tests should initially be written against
a shell where we expect the tests to fail. This approach also forces people
to think about the interface more carefully.
-
We never strictly forced all members on our projects to start thinking about testing
before coding. I went to a Kent Beck lecture the other day and he stressed how
important it was to have a community of people encouraging you and keeping you on
track. When you don't feel like doing the test you should turn to the person
next to you and they should set you straight.
-
Our attitude was always we need to get the job done as quickly as possible.
We also factored in relatively long system testing phases at the end of the project.
When testing we would start off by attacking the obvious bugs first and only quite
a bit later move on to important system logic. What I expect from test driven
development is to be able to hand over a project to the QAs where they can get straight
into the important system logic (which may be very difficult to script) because
the development team has already made certain that arbitrary bugs don't exist.
An article that I'm going to get my colleagues to read is 10
Ways to Make Your Code More Testable.