Comments on: Does unit-testing deserve its own DSL?

By: schlenk

schlenk — Tue, 11 Dec 2007 20:07:09 +0000

In very dynamic languages such DSLs can be done with not too much overhead.

tcltest for example is a little test DSL, but for the stuff you wanted one could use things like variable and execution traces and maybe coupled with the unknown handler. Just delete all commands from a slave interpreter other than [unknown] and inspect what gets called.

For some intro to Tcltest http://www.tclscripting.com/articles/apr06/article1.html

By: Martijn Faassen

Martijn Faassen — Tue, 11 Dec 2007 19:21:37 +0000

I’m not really much into mock objects, but indeed there are quite a few mock object libraries in Python that can do things like that.

http://labix.org/mocker

is a recent one that comes from a very good Python programmer. I should try it out with doctests one day. The examples in the mocker documentation are probably doctests already.

By: Hans-Eric

Hans-Eric — Tue, 11 Dec 2007 19:06:41 +0000

Good point! Probably that’s the reason we don’t see any unit-testing DSLs out there.
A thought: Shouldn’t a reflective programming language like Python be able to implement a unit-testing framework with “unconditional mocking”, without the need to create a new language? The framework should be able to generate the mocking code and inject it in the source code during execution. Maybe this has already been done?

By: Martijn Faassen

Martijn Faassen — Tue, 11 Dec 2007 18:34:05 +0000

Unit testing should be in the way as little as possible. Learning or reading a new programming language seems to be “in the way”.

The best way I’ve seen unit testing disappear into the background is with doctests:

http://en.wikipedia.org/wiki/Doctest

http://blog.ianbicking.org/2007/11/27/java-bdd/

That doesn’t take care of any mocking concerns, of course, but another language just to write tests seems overkill.

By: Adam

Adam — Mon, 10 Dec 2007 22:36:50 +0000

I’d personally say it does from my experience in programming!