[erlang-questions] I Hate Unit Testing...

[pax]

> However, since I'm too lazy to write test code, I'm definitely too  
> lazy
> to read much about writing test code and even less likely to bother to
> learn a whole framework. I have my hands/head full learning the
> Erlang/OTP libraries as it is.

In my experience of TDD, writing the tests is the best way to learn  
the language, it's APIs and the platform in general. I like tinkering  
around, but I'm just as busy as the next guy, so extended debugging  
sessions are out, and much as a love dbg:tracer and its wares,  
trawling through the traces to find a bug isn't my idea of fun.

> MUCH TOO COMPLICATED!! It's inspired me to try another version of
> "utest" that does stuff more like the following:
<snip>
> What do you think? :)

Looks good - I'd use it. I'm currently using common_test, and although  
everyone seems averse to it because of some imputed complexity (it  
actually seems very simple to me), I find it an excellent tool. In  
particular I like that it compiles my tests for me, deals with code  
coverage, producing reasonable test/coverage reports in html and has  
some utility libraries for working with various managed protocols. The  
way it handles configuration and test data takes a bit of getting used  
to, but once you're over the hump (and have some handy scripts to  
automate things you can't be bothered to remember), it's all good  
really. Incidentally, the main reason I use common_test in favor of  
eunit, is that it can be configured/modified to run as a continuous  
build+test environment and has good support for running master/slave  
nodes. It effectively acts as a continuous integration server.

> There is an Erlang QuickCheck, but it's a commercial product by Quviq.

Yes this looks promising (I wouldn't leave home without the Haskell  
version) but I'm on a tight budget! :)

> I really am that lazy (or maybe just that stupid) that I don't want to
> change gear into writing (and debugging) a test module. Even when I do
> actually pull my finger out, I generally delay doing it by which  
> time I
> have forgotten half of what the module was really intended to do (i.e.
> the detail of the spec), and so I have to remember all that and it
> becomes a big chore.

I hope I'm not going to come across as a zealot here. I too write code  
without testing it - when I'm prototyping (spiking as it were) and  
mucking around learning new things. When it comes to writing  
production code though, the only tests I leave until after I've  
written the module/application is the integration tests - which I also  
use common_test for. This has more to do with your choice of process/ 
discipline than tools I think. The TDD approach is intended to get you  
thinking about the design/api from the onset, and writing the tests  
first forces you to do this. It also (if you stick to the method)  
stops you from writing code you "might need" at some point in the  
future. I like writing code, so I tend to tech-fest given half a  
chance. The "red, green, refactor" thing helps me to stay focussed -  
but that's a personality thing at best.

> On another note, someone mentioned Cucumber... well hmmph. That's all
> very nice for your corporate stakeholders, but it's waaaaayyy too
> verbose for any developer I know to be bothered with.

I have to foray into Ruby quite a bit a work, so I'm used to rspec and  
cucumber. Whilst I see the annoyance - having worked with quickcheck  
in Haskell, writing any kind of unit tests for referentially  
transparent code seems a pain - I think cucumber is a world of comfort  
compared to JUnit, NUnit, JMock and the like.

> Yep, interesting and valid points, and there's a distinction to be
> made.
>
> My suggestion is for Unit Tests and so really doesn't cover System/
> Subsystem Tests where the issues you describe will certainly become
> major considerations. For that kind of testing, I have other ideas
> cooking around - in particular there's big inspiration to be had from
> Joe's UBF contracts...
>

Totally take your point about that. UBF looks very promising. I'm sure  
there are many ways to automate much of the repetition in defining  
systems/integration tests.