Is it just me or does anyone else miss being able to create something
When I write customer paid for software I strive to apply the best
practices to ensure they have high quality, low bug software which is
well-factored with the goal that it is easier to maintain and extend
over its lifetime, assuming there will be developers added to the
project over its lifetime that were not there for its original
When I write software for myself I tend to flip flop. Sometimes I am
writing things to learn or play and I don’t test. Sometimes I want to
work on my ability to write well designed testable software, so I do
Also, don’t forget that sometimes when producing software you need to
SPIKE some things out, which means you code upfront to investigate
(kind of like prototyping) and then when you figure out what you want
to do, or how-to do it you scratch the prototype and reimplement
Once you start writing all the tests your time is now
increased by a factor of 10.
Here’s another perspective to look at it from. When you write testable
and tested software you spend less time coming back to it to track
down and fix erroneous bugs. There is a much higher risk you will have
to track down and fix erroneous bugs when you don’t test (or don’t
test well there is a difference).
There are also the things to account for like when you design for
testability and the fact that you usually end up with simpler
components which are easier to add to, extend or change. So as your
program grows and changes from your customer’s perspective you are
able to maintain fluid momentum for changing the code as well. When
you don’t test there is usually a lot of momentum in the first few
weeks, but then development slows down and even comes to a halt
because the codebase is not well factored, and bugs are much more
easily introduced with these changes and you spend more time tracking
down bugs, fixing bugs and trying to understand the codebase.
So I don’t agree with the factor of 10 because when you don’t test you
spend a lot more time over the life of the project tracking down bugs,
fixing bugs, and a much more difficult time changing the codebase to
grow with its users needs and your customers desires. All of the time
spent doing these things should be added to the time it took to
originally develop a feature upfront since it really wasn’t done.
People also have different levels of software development skills
(design, testing, object decomposition, etc) and they can produce
things at different speeds so a factor of 10 for you may be a factor
or 0 for someone else.
Now this is a simple example, but that is a lot of extra tests for three
lines of code. I don’t know if it is just me, but it takes away some of
the fun in being able to see results right away.
First thing: do not stub or mock expect the object under test.
When you’re testing a controller do not “stub!” the controller and do
“should_receive” the controller. This removes the value you get for
the controller itself. There are exceptions to this rule, and this is
because people violate the use of mixins. That is for another
I know that Pat said that the
too much testing, but I’m going to be more forward. It is not too much
it is testing the wrong thing.
I understand that with more complex code it may be easy to make a change
that could have unexpected effects elsewhere. In the above example,
there is no logic that would ever get changed by accident on later
updates at least not by anyone who knows what they are doing.
Maybe I am way out in left field with the tests that I write, but the
tests above are done using the fails, update, pass sequence. I just
can’t see the reasoning for writing all these tests for something so
So when the application gradually becomes more complex do you think
get to a point and say, “well I need to test this now?”. Unfortunately
even if you do
do that when you get to point there’s a really good chance you didn’t
write the code
for testability, so the barrier to test is much higher, and it’s
easier for people to
give in and not test at this point because it’s now to difficult to
test, and they can’t
spend a long time fixing bad code they’ve written.
I guess my thing is that I like writing tests when they will eliminate a
lot of manual testing ex automated scheduling class. This would require
a lot of different tests to make sure that the scheduler works as it
should. I also don’t have a problem with model testing seeing as there
may be some logic within the model that is unique to it. I do find view
testing to be a very unenjoyable, and I haven’t event looked at stories
Testing is not about developer enjoyment. It’s about producing high
low bug software in a way that allows you to sustain a consistent
pace over the lifetime of the project.
Although I do get enjoyment knowing I’m producing high quality software.
I am not trying to say that testing isn’t good and that everyone is on
the wrong track, but rather wondering if, as in the example, am testing
more than I should be.
I think you’re experiencing growing pains. Thank you for posting your
concerns and questions. I used to have some of the same questions
you’re having. Hopefully
my response has been helpful to raise some counter arguments to your