Write your own unit test "framework"

If you haven't already done it, I recommend you try writing your own unit testing framework. Actually, do it several times, in several different ways.

The existing unit testing packages are sizable pieces of software, and I'm not recommending you spend weeks on this effort. Keep it simple. In fact, the bare minimum to get started with TDD is almost nothing:

Loading Gist 115890d1949a7971e2e2...

Sure, there is value in automatic test discovery, in rich asserts, running all tests even when one fails, reporting, etc. But you don't have to have those things to get started. (Remember this next time you are away from WiFi and have a programming idea.)

Starting from this point, experiment with different ways to write a unit test framework. Some ideas to consider:

• What's the #1 feature you miss the most in the above example?
  
• A natural way to extend asserts in to your domain.
  
• How easy is make the mistake of writing a test that never gets run?
  
• If my tests are super-fast, how much overhead is there in test discovery and reporting?
  
• Reporting that points directly to the site of the failure.
  
• How much boilerplate does a developer have to write?
• Test discovery: reflection ([Test]), inline functions (describe(()=>{})), or something else?
• If you only supplied one built-in assert, would it be "Assert True", "Assert Equals", or something else? What are the implications?
• Try both traditional asserts (AssertFoo(result...)) and fluent asserts (Assert.That(result).IsFoo(...)).

Let me know what you find.