Do you still Write Tests First on code that is churning hard?

Hello Specmeisters!

I have a bit of a philosophical question for the TDD witches and
wizards out there. I’m working on some code that is really
churning… It’s doing complicated calculations, but the actual
desired results are a moving target. The acceptable values, and even
the structure of the software’s output are changing constantly. The
internal architecture is changing rapidly, and I’m constantly throwing
away methods I no longer need.

This has resulted in me no longer writing specs on this part of my
codebase. They just become obsolete very very fast. Changing the
specs constantly feels like a pointless doubling of my effort. Specs
seem to help with debugging and verification that the software is
performing as expected. But I’m spending most of my time trying to
figure out what I should be expecting. I verify that things are
working quickly and informally, because it’s likely the definition of
“working” will change before the week is up.

Am I being stupid? Is it really a pointless doubling, or am I
creating more debugging time for myself than I’m saving without
writing specs? Should I be more religious about Test First?

Thanks in advance for the insights,

hi there,
well I’m not a meister myself, but spec-ing something you don’t know the
outside result is a bit hard for me.

I normally work in two modes:

  • hacking mode: that’s when I’m trying to “see” if I can do something,
    the result will run, getting to know the problem and such. In these mode
    “only” write specs that keep me going further, but those look more like
    units. This specs or test-units-specs are something I see as tests that
    later are a kind of code history (“residual tests” keeps coming to the
    of my head) and keep them as long as they don’t start becoming a PITA
    and of
    course are still valid :slight_smile:

after I know my hack will do, and know the problem better I switch to
typical outside in

  • bdd developing mode

so the thing is outside in only works if you know the outside. And also
to spec only the “right” amount. But for maths calculations I would for
sure TEST

some thougts, hth

2010/2/19 Erik P. [email protected]

Testing should answer this question for you, regularly: How do you
know it works?


On Fri, Feb 19, 2010 at 12:59 AM, Erik P.

I kind of follow a similar principle here. Many times I will write app
code because in not sure how to pull of the functionality I’m try to
do. Once I can confirm that I’m getting the expected results, I take a
mental note of what I did, remove the code, and drive it out again
with the spec.

I like this method a lot because the repetition helps me to lock in
the logic. Kinda like how people say you really know a topic if you
can teach it to someone else. The spec almost because that someone
else I’m teaching.

So in short, I think you’re safe in your approach, but don’t leave the
code-first spec-second code in production.

Frank L.
Catchon Media
[email protected]

On Feb 19, 2010, at 7:21 AM, Matt W. [email protected] wrote:

On 19 February 2010 08:59, Erik P. [email protected]

This has resulted in me no longer writing specs on this part of my
writing specs? Should I be more religious about Test First?

Thanks in advance for the insights,

rspec-users mailing list
[email protected]

I think you can consider writing a completely separate spike to explore
subject, so long as you make absolutely certain that you do not merge it
into production code. To avoid that temptation it really should be
Speculating a bit however, I think your process for developing this part
your code maybe very wrong. It sounds like your looking for
for hacking - which generally is a bad sign - and that maybe you need to
take a step back and look at different approaches. Maybe instead of
on results you could focus on process e.g. to calculate foo I first need
bar etc. or perhaps you need to go more granular and create some tools
simplify your calculations. Finally if you have any long methods in your
calculations (> than 5 lines) refactor them. Decomposing them into
methods could reveal alot about the structure of your problem



On 19 Feb 2010, at 08:59, Erik P. wrote:

This has resulted in me no longer writing specs on this part of my
writing specs? Should I be more religious about Test First?

Thanks in advance for the insights,

Here are some rules of thumb I would use:

If requirements are churning, I would try to use high-level acceptance
tests (e.g. with Cucumber) to firm them up.

If I can’t firm up my requirements, it’s because we’re still going
though a discovery process - we don’t understand what the problem is,
let alone the solution - and that means it’s too early to write any
production code. I would happily write code without tests at this
point, but I’m going to be loud and clear about the fact that the code
I’m writing is a spike, and will have to be thrown away and re-written
before we go live. This kind of code is much more valuable than you
think - most of the value is in the learning that goes into your heads
as you do it, rather than in the cobbled-together, un-tested code you
write. Writing code like this can be fun, but never be tempted to
check it in!

Once the requirements start to stabilise (but are still changing) I
often go through a process where the design is still churning as I try
to work out how I best want to solve the problem. At this point I
would rely on those high-level acceptance tests to cover me and only
write specs for parts of the design as it started to stabilise.

The thing you have to remember is the point of TDD/BDD is to surface
uncertainly and misunderstanding early. Once you get past the
discovery stage, having the discipline to write tests first will
reduce churn, because you ask more questions (and make more decisions)
before you actually sit down and write code. If you don’t have enough
information to make those decisions though, don’t be afraid or ashamed
to write a spike, but make sure everyone on your team understands the
distinction between that and production code.

+447974 430184

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs