Introduction
I spent a lot of time exploring Parrot testing with Test::More in the last step. That’s because I want to start building larger projects, and testing is a vital part of most projects. Another major part is a properly organized workspace with a script that can simplify testing or other tasks.
Creating a Simple Project
A nice Parrot project layout includes a t
folder for tests, a lib
folder for
library code, and a setup.pir
file to drive the whole thing.
What gets placed in setup.pir
? Not much, considering how much it does.
setup.pir
takes advantage of the Parrot distutils module for a whole range
of tasks. All I’m concerned about today is testing, so my setup is going to be
rather lightweight.
This is not exciting code, but it is enough to see what distutils can give me.
The first command line parameter is shifted onto a dummy register variable,
because I don’t really care about the name of setup.pir
from within
setup.pir
. Then I load the distutils bytecode so I can get access to the setup
subroutine.
This setup.pir
will get more complicated as we go on, and you will
definitely see more complex setup.pir
files out in the wild, but this will
get us started.
What happens when I tell setup.pir
that I want to test?
Well of course it failed. There aren’t any test files, and setup.pir
wouldn’t
know how to run them if there were!
I’ll fix the second part first.
Parrot allows you to use named parameters for some subroutines, and setup
takes full advantage of that feature. If you’re used to Perl or Ruby, named parameters look a lot like a hash. That’s close enough for our purposes. A named parameter generally follows a simple format:
Thankfully, distutils.pir
is a well-documented module, and you can find details about the many options by checking the documentation.
I only care about a single option: prove_exec
, which tells setup
what program
will be used to run the tests. Why does setup
care? Well, Parrot is a VM. Your
tests can be in PIR, NQP, rakudo, or even a language of your own design.
The parrot-babysteps are about Parrot PIR, so it makes sense that the tests will be in the same language.
Oh yes, the tests. Let’s write one. I’ll follow the convention I see in the Perl world of a number followed by a description for the test filename, and the test itself will be for a simple area calculating function.
So - this should fail, right?
Excellent. Parrot didn’t just tell us that the test failed. It also told us
about some unexpected output from our test script. What’s that unexpected
output? Oh, something about not having a subroutine called area_of_circle
.
Let’s fix that by adding a new library file called lib/area.pir
, and adding
the missing subroutine.
This is code borrowed from step 2 and dropped into a subroutine.
Don’t forget to include this library code from your test file.
Did it work?
Yay!
Hold on a second. I snuck an extra argument back when I wrote the is
assertion. What was that all about? Well, Jonathan Leto explained to me that is
takes an additional argument for precision, which is useful in the fuzzy world of floating point math on a modern computer. The 1e-6
requirement asks Parrot to make sure expected_area
and actual_area
look the same down to six places past the decimal point.
This approach of writing the tests before you write the code is called TDD, for Test Driven Development(http://en.wikipedia.org/wiki/Test-driven_development. I like TDD because I’m basically describing the next thing I want my library or application to do. That’s perfect for me, since I’m such a chatty person. Well, I’m chatty when typing at the computer.
You don’t need to follow a test driven approach, but other developers will like you more if you consistently test the code you write. The easiest way to consistently test it is to write the test before you write the code.
Conclusion
Combining what we’ve learned about Test::More with setup.pir
allows us to
confidently build more complicated applications, testing as we go along. It is
true that all we know how to do with setup.pir
at this point is ask it to run
tests for us, but even that can save a lot of work.
I don’t know about you, but I’m ready to take another look at that star catalog.
Added to vault 2024-01-15. Updated on 2024-01-26