[erlang-questions] I Hate Unit Testing...
Wed Jan 28 23:57:52 CET 2009
> However, since I'm too lazy to write test code, I'm definitely too
> 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:
> 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
> 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
More information about the erlang-questions