This is second part in series about implementing finite-state machine DSL in Hy. The first part is here. Lets start by comparing where we left of in the previous post and what I ended up with in the end (or at least at the time of writing this entry).
I have been using Nose for the longest time and it’s my go-to tool for running tests. Nose is very no-nonsense and has very sensible defaults (to me at least).
Writing a test in Hy that gets discovered and executed with Nose is pretty straightforward. One just needs a correct naming convention and everything happens more or less automatically. However, by applying some standard lisp practices, one can cut down amount of the code needed quite a bit. In this post, I’ll present how my style of writing tests have evolved over time and what kind of measures I took in order to write minimum amount of code.
Getting nosetest to work with Hy was easier than I thought in the end. The trick I used was to create a Python module that will act as an entry point. In that module I first import Hy, which in turn lets me to import my test modules:
import hy from .test_person_repository import *
After that I can run nosetests and end up with:
tuukka@new-loft:~/programming/python/sandvalley/src/sandvalley/tests$ nosetests .. ---------------------------------------------------------------------- Ran 2 tests in 0.015s OK
Pretty nifty I must say. Having to import everything from modules in a entry point module is a bit hassle, but that’s something that I should be able to automate.
The same method can be used to call Hy code from Python program.
In the beginning (like, couple months ago), I thought that in order to test certain features in my game, I had to either write really long-winded setup functions or access filesystem and load data from there. I chose not to access filesystem, because it would create nasty coupling between some datafile and my tests, instead I wrote long-winded setup and hid it away in class called IntegrationTest.
That module started accumulating all kinds of cruft over the time, stub models, stub random number generators and stub configurations. It worked ok though.
Today I emptied that module, threw away IntegrationTest Class and rewrote the tests that were using it. In the process couple tests got deleted, because I didn’t need them anymore. Now setting up is done with those nifty little builder objects, that can create pretty much anything I want in just couple of lines.