pages tagged testingyakkinghttp://yakking.branchable.com/tags/testing/yakkingikiwiki2017-04-05T11:00:12ZNew project? Start with the scaffoldinghttp://yakking.branchable.com/posts/scaffolding/Lars Wirzenius2017-04-05T11:00:12Z2017-04-05T11:00:06Z
<p>So you're starting a new project. You have an idea for something, and
a vision for how to implement it. What should you do first?</p>
<p>If you're like me, you burn to start with the interesting coding bit
first. After a few hours of furious typing, you've done the fun bit,
and you need to add all the boring bits: automated tests (unless you
did TDD, and even then there may be missing tests), documentation, a
manual page, a README, perhaps packaging (Debian, RPM, language
specific), a CI project, a home page, etc. There's a lot of it. That
is usually when my enthusiasm fades. A lot of my projects end up as a
single file in <code>~/bin</code>.</p>
<p>I call the boring bits scaffolding, and I've learnt that it pays to do
them first. Not only is that often the only time I will actually do
them, but once the scaffolding is in place, the fun bits are also more
fun to do.</p>
<p>If I have unit and integration test frameworks in place, adding
another test is only a small incremental task. If I haven't got them
in place (particularly for integration tests), I tend to postpone
writing tests. No chance of TDD, whereas when I put in an integration
test framework, I often to TDD at the program level, not just at the
individual class and method level.</p>
<p>Likewise, if I start by writing a manual page, adding another sentence
or paragraph is easy. Also, writing a manual page, or any
documentation, clarifies my thinking about what the program should
actually do, and how it should be used. This makes writing the code
more pleasant.</p>
<p>Having CI in place from the beginning, means the tests I write get
exercised from the start. This finds bugs earlier, even if I run my
tests manually as well. CI never thinks "I can run test faster this
one time by taking this clever shortcut".</p>
<p>Of course, putting up a lot of scaffolding takes effort, and it's all
wasted if you don't actually want to write the program after all.
Sometimes what sounds like a brilliant idea on the last train home
from a party, makes no sense at all in the morning. (Personal
experience, ahem.)</p>
<p>Thus it may make sense to start with a simple proof of concept, or
prototype implementation to verify the soundness of you idea, then
throw that away, and set up scaffolding, before you start writing
production code.</p>
<p>My latest personal project has a manual page, unit and integration
tests, Debian packaging, a CI project, and a home page. I can install
it and run it. It does't yet do anything useful. Before all this, I
wrote a prototype to prove the idea I had, and threw that away. Some
time this year I will start dropping in modules to actually do useful
stuff, and that'll be easy, since I won't need to worry about all the
boring bits. As soon as it does anything useful, I can also point
friends at a Debian package and ask them to try my latest masterpiece.</p>
<p>What's more, I have a better chance of getting them to help by writing
a module they need themselves, since they just need to write the
module and don't need to worry about the rest.</p>