I'm interested in ways and means for learning (a) programming language(s) efficiently. I believe that using Unit Test concepts and infrastructure early in that process is a good thing, even better than starting with "Hello world".

Why: To write a decent program even for a toy/restricted problem in a new language, you'll have to master many heterogenous concepts (control flow & variables & IO ...), you are tempted to glance over details just to get your program 'to work'. Putting (your understanding of) the facts about the new language in assertions with good descriptions (=success messages) enforces thinking thru/clearness/precision. Grouping topics and adding assertions to such groups is much easier than incorporation features from the 2. chapter of your "Learning X" book to your chapter 1 program.

Why not: 'Real' Unit Tests are meant to output "1234 tests ok; 1 failure: saveWorld() chokes on negative input"; 'didactic' Unit Tests should output relevant facts about the new language like

perl6 10-string.t
# ### p5chop
ok 13 - p5chop( "cbä" ) returns "ä"
ok 14 - after that, victim is changed to "cb"
# ### (p6) chop
ok 27 - (p6) chop( "cbä" ) returns chopped copy: "cb"
ok 18 - after that, victim is unchanged: "cbä"
# ### chomp

So (mis?)using Unit Tests may be counterproductive - practicing actions while learning you wouldn't use professionally.

How: Writing 'didactic' Unit Tests in languages with lightweight testing systems (Perl 5/6) is easy; (mis?)using more elaborate systems (JUnit, CppUnit) may be not worth the effort or not suitable for a person just starting with a new language.


  1. Is using Unit Tests as a learning tool a bad idea?
  2. Can the Unit Test tool(s) of your favourite language(s) used didactically?
  3. Should implementation details (eventually) be discussed here or over at stackoverflow.com?

2 Answers 2


This concept of learning through unit tests already exists. In the implementations I've seen there a set of unit tests with missing values and the user has to put them in to get the test to pass.

Two of these that I have personal experience with are:




I'm sure you can find others for your particular environment or just create a suite yourself.

They are a great learning method.

  • +1: Thanks for the keyword "koan", the links, and the encouragement. The difference to what I have in mind: Successfull koans don't present the relevant facts - instead of "Knowing it should expect true has expanded your awareness." I'd like to see "True (and neither true or -1) convey Truth". Mar 6, 2011 at 14:41

Chapter 8 of this book ("Clean Code" by Robert C. Martin) describes how to work with a boundary of two systems and (among other things) introduces the concept of Learning Test.

The main idea is, when you have Subsystem A dependent on Subsystem B, to write automated tests against various functions of Subsystem B in order to learn how exactly to use it to get the desired results. You end up with a suite of automated tests of Subsystem B and future breaking changes of Subsystem B won't catch you by surprise.

I think you are on to something with your idea to apply the learning test concept to the programming language itself.

Not the answer you're looking for? Browse other questions tagged or ask your own question.