After a long break, we have a fantastic katacast to present to you. Antonio Lucca contacted me with a new, C# version of the codebreaker kata. I started watching it and was blown away. Is that C#? In Vim? With autotest-like functionality? Super sweet! Without more rambling from me, here’s a bit about Antonio:
Antonio Lucca is a software journeyman, thinker and learner, and Scrum Master. He lives in Milano, Italy, at the moment. He is interested in principles and practices that helps making software development sustainable, efficient and fun.
Here’s what he has to say about doing the kata:
The first test cases are the non positional matches, then by some refactoring everything comes up to a linq expression.
The next test is related to a more intriguing case: Avoid counting twice a color that has already a match (the “mm” expected as result for a “yyxb” guess against a “rgby” secret, where the actual result is “mmm”, counting ‘y’ twice).
I commented that test for a while, and then did some refactoring until the base code was ready to implement just the logic needed to let that test pass.
After that I implemented the positional match as a special case of the non-positional match, and then put them together in the Mark method.
The tools that I used are autobuild (from google code), nunit growl addin, and… gvim.
One of the awesome things is the toolset he is using. You should watch it first, then come read how he did it. Here’s a write-up of this:
I have a visual studio solution, but should not be not strictly required, however I didn’t try without having the visual studio solution. (I mean a build file in .sln format, suitable for the dot.net sdk msbuild command line tool).
If you have only the dot.net sdk could work as well, as long as you can modify the autobuil.build nant file, that should be straghforward. however I havent tried yet. the free c# express edition to create solution file may works as well.
Another possibility is avoid reference to the solution and modify the autobuild.build nant file to simply compile the sources via csc compiler.
However this is my configuration:
1- you have a visual studio format solution folder of a project that referenced the nunit assembly (nunit.framework.dll)
2- you have installed the autobuild from http://code.google.com/p/autobuildtool
3- you have nunit version 2.5.5, and nunit growl notification addin, and growl as well
4- you have a output named output (or whatever) where you copy “stuffs” as described in http://timross.wordpress.com/2009/08/04/continuous-testing-in-net/
5- you modify there the autobuild.build file in the output directory to let it reference the solution file of your project (or call the plain source files compilation via “csc”. As I told, I didn’t try)
6- on that file you change the “run-unit-tests” target so that it will call the external command line nunit-console that takes as argument the assembly generated by the build, (usually in bin\debug) redirecting the output on a file. Avoid using the nant2 task because it didn’t work (to me).
7- open two different windows command prompt (cmd). One where you can launch autobuild.cmd, another one simply to show the nunit-console output redirected to the compiled file (dll assembly or .exe). you need to show the file via tail -f. So a tail tool should be available as well, for example having cygwin installed.
8- should be ready. Be sure that growl is running. Create a single failing test and if you launch the (included in autobuild) nant to autobuild.build file it will build the project and execute the tests, and the nunit notification should “growl”. Sometimes modification of the solution file (.sln) can be required, because, for instance the build does not see the output folder for the compiled.
If the point 8 is ok, then launching autobuild.cmd should be able to do everything in background and so any change in any source file of the project will make the solution be rebuilded and test executed and notified in growl and in the output file (accessed via “tail -f”).