Tuesday, November 10, 2009

Unit Testing: Are they valuable?

In my opinion no.

The first company I worked in, Unit tests were the holy grail, something they always wanted to do, but our codebase was so old, so complex and so intertwined it would have taken months of dev effort to write these tests and management didn't see the benefit. I left that company with the opinion that Unit tests were great, it would solve all problems and I would be a super effective programmer.

Enter my current job, I came in too a near completed version of our product and we had some serious server issue, tricky logic was just confusing us and in the end it was decided that unit tests would save us, bring us out of the maze and into the light, it was then I learnt the truth, unit tests are clunky and ugly.

Our problem was that we made the tests after we wrote the server code. So you write the test framework, run it, it goes red, you change it and run it and it goes green, but does it go green because it actually is correct or because the test suffers from the same logic issues that causes you to write the test in the first place.

So in theory you write the tests before you start the code base. So you write the test then you write the function, test the function rinse and repeat. Now some people would argue that this is the correct way to do it, but for every line of production code you have you have a line of testing, and the testing isn't guarenteed to help. Everytime you refactor you need to rewrite the tests, which could lead to the problem that we had that your test is no longer accurate.

Some people would say that writing the tests allows them to nail down the perfect design and stops the need to refactor. To that I say, anyone who says they are such a good developer that they never need to refactor their code is a liar. Code evolves with time and refactoring is the way to keep the codebase lean and clear with this evolution.

Now I am not saying that all tests are wrong, I am just saying that the fine granularity of Unit tests are wrong, Intergration/Acceptance tests are an entirely different beast and exceptionally value in a development suite.

For more information about this please read this following blog as it is the one that got me thinking about unit tests

Wednesday, November 4, 2009

Functional Spec, how I hate you.

I have very little to say on the matter besides it is crazy that some people love doing that sort of paperwork.

If I am out, drinking or whatever, in person I can tell you what my application does no worries. I can go in depth about why we did what we did, what pedagogy we are peddling, the whole nine yard. Sit me infront of my machine and ask me to write it up, I fail hard. Oh so hard.

In the end I went for the child book analogy and made SO many picture. Oh so many.

The due date for the application I am working on has jumped forward by like 3 months and each day that goes by I am less and less certain that we can make it. In structure we are as rock solid as ever, our back end replaced from a standard server to that of an ejabbered XMPP one, adopting the metaphor of the old school mIRC chat room. So with an properly configerd erlang back end, our server never crashes, which is good.

The concern comes that we will not have the time to test the edge cases that users always manage to get themselves in the first minute they pick up the machine. Our testing team are doing an amazing job, coming at the application from various angles with a sledge hammer but even they cannot work so many miracles before they can't find anymore.