When I edit Guile code in Emacs, there are some tools relying on the environment to work (i.e. Emacs extensions like Geiser, Flycheck-Guile).
Parts of this environment are project specific while others are shared across projects.
So I ended up setting manually my environment usually following these few steps:
My last post was full of errors ! I guess I got lost in the REPL state and faced ghosts, like variables and procedures no more defined… In this post, I give you a new version of the code without errors. You also get a bonus feature : the failing tests are named in the summary.
In my last serie about building a testing framework à la xUnit left me with a weird feeling. Following Kent Beck's execution, from the book « Test Driven Development by Example », the exercise of thinking the Scheme way harder than I thought. I ended up with a shaky copy of the Python implementation. So I decided to let time passing by and come back to it to see what I can do differently. In the meantime, I watched a video of Andy Balaam where he showed a small illustration of the idea of Lambda Calculus and how it can be leveraged using a Scheme. That inspired me. Let's see how much, step by step…
The next item on the todo list: Report failed tests. The last chapter let the state of the test suite in a shaky state. Indeed, the last one is still red!
According to Kent Beck, the following chapter is like going one step deeper to deal with a more specific – smaller grained – as he said. To ensure our learning base (the tests) is rock solid!
The next item on the todo list is Invoke tearDown afterward. But before doing this one, Kent wanted to take care of the order in which the procedures are called. This brings a new item : Log strings in WasRun.
So in this chapter we are going to implement a small logging system then the tearDown test fixture.