#srfi — Public Fediverse posts

I like #UnitTesting. The original #SUnit was wonderful, but it was ported to the land of needless complexity and became #JUnit which begat a whole lot of add on pieces. A simple idea buried under feature creep.

My favorite testing framework is #SRFI-78 https://srfi.schemers.org/srfi-78/srfi-78.html which provides a little reporting and summarization but it doesn't interfere with the tests. In C the MinUnit header file from Jera Design is beautiful. I use a beefier implementation, again to get simple reporting.

#Forth has ttester. It is terse to the point that I am tempted to add some reporting. So far I've resisted the temptation.

As in SRFI-78, you test a phrase and compare against expected results on the stack.

T{ 1 2 3 drop -> 1 2 }T passes
T{ 1 2 3 dup -> 1 2 3 }T fails

I'm writing tests for my library code and use them to test expressions in my AoC efforts.

I'm trying to decide if I should include the test in the library source (compiled conditionally) or in separate test-* files. #Programming

Hot take: in terms of the language specified treated independently of the social process of standardization itself, everyone's beloved #r5rs is actually the worst post-#r4rs scheme, and #r6rs is easily the best and most revolutionary, hence the controversy surrounding it.

#lisp #srfi