I hung out with Chevy Ray of FlashPunk fame the other night, and he shared with me some programmer wisdom. Which I now share with you: warm up!!
I always make it a point of mine to spend enough time warming up before physical activities. Whether it’s going for a run, dancing, rock-climbing…anything physical. I always make sure to spend the first few minutes doing some light but similar exercises, stretches etc. It literally serves to warm the joints and muscles, because they become more flexible and powerful a few degrees above body temperature, but it also serves to put me into a more self-forgiving mindframe. I suppose it’s because when I warm up it really drives home the point that I’m human, that I’m not perfect, and that it can take me a little while to get into the groove of something so that I can do my best work.
What Chevy pointed out to me was warm-ups can be made for mental activities as well. Some of the best teachers I know get their students into the right frame for class by throwing around some open brainstorming or opinion questions: mentally warming their students up for the subject at hand. And it’s just as useful to put this idea into practice for the dark art of computer programming. And I don’t know about you, but being more aware that I’m human, not perfect, and need to get into the groove of something goes a long way towards helping out that pesky programmers block
So today as I start my programming, I’ll be taking Chevy’s advice: start on a few small things, just change some colours around or tweak some variables, write a piece of code you’ve already written before, change some formatting or variable names. Just to warm up. Don’t get buried in changing little things, just get the mind thinking about programming before moving on to what needs to be done today.
After a long period of being injured, I’m beginning my foray back into the world of parkour. It seems like no matter how often I seem to make mistakes and hurt myself during this sport, I keep coming back to it. I’d like to think that maybe the universe is telling me that I’m supposed to be a traceur; gently, inevitably pulling me back towards parkour everytime. Of course, it could also just be my own bloody-mindedness
This time there’s a difference in how I find myself training though. While before it became about power, ability; “how big is that, reckon you could make it across?” etc. This time though, the moves don’t matter to me. This time I’m concentrating on the movement between the moves. I’ve realised that’s the place where true efficiency can be discovered. And I don’t think I would have realised this – or even gotten back to regular training this quickly – without the help of the guy I train with. In fact, there’s a lot of situations where I actually needed someone else just to get me to do something I’d always wanted to do.
When I think of the things I’ve achieved, more often than not there’s a teacher or friend there that motivates me and pushes me past my limit. When I think of the things that I’ve failed at, or am still meandering about trying to do – they’re things that I’m trying to do alone, and for no-one but myself. I guess the people in my life that aren’t me are the greatest motivators
I think of my new obsession – Bikram yoga – where the teacher pushes each and every one of us to try harder than we want to, and for me it works. After just 3 classes I can touch my toes, knees straight, for the first time in my life!
I think of dancing and my amazing teachers, always giving me new challenges and watching intently as I take them on. And the partner that’s always in my arms, hoping to understand the move we’re learning, or try something new with it.
Most especially I think of my mentor, James. Without him I never would have pushed myself into the places I hate – the bars and pubs and clubs where the music is played too late and the people throng around me spilling drinks – but because I did I now have no fear in meeting new friends whenever I’m networking or out alone.
So the point of this week’s – this month’s – musing is that oftentimes bringing someone else into a project, being directed by someone else, or wanting to create something for someone else is the greatest motivator of all.
Posted by Tatham
| Tagged: Musings
I’ve been writing my own code using Test Driven Development (TDD) for about 6 months now, and at the same time have found myself professionally working for two different non-games firms. In this time I’ve had the opportunity to try using agile methodologies – and unit testing – in a few different environments: business through to casual. I want to share some thoughts and musings from this time.
Firstly, tests are hard. Plenty of people have covered this point in the blogosphere and beyond, but until I actually tried it just never truly sunk in how hard they are. It’s one thing to be “informed” that “agile is difficult”, but it’s an altogether different experience when I’m staring blankly at my screen with absolutely no idea how to write a test for this functionality I want. And those moments happen. A lot. And they are truly a struggle to get through, but I learn very important lessons once I figure them out. And yes, it takes dedication and effort to figure them out.
Secondly, getting tests onto legacy code is even harder. I have a secret obsession with Michael Feathers’ fantastic book Working With Legacy Code, which gives some plentiful ideas for how to add tests to code that was never designed with tests in mind. Armed with these suggestions, some experience writing brand new code covered by tests, and the right environment, one can get tests on just about anything. In a casual environment i.e. When I’m my own boss, I find it pretty easy to see the benefit for refactoring old code to make it testable (I’m easily convinced though) . Things get a bit iffy when the work is for someone else though. In my experience there are often factors preventing the system going under test that have absolutely nothing to do with the code. People can be lazy, or busy, or scared of tests. Unless the whole team makes a commitment to getting agile, it’s probably not a good idea to spend hours finding seams and getting code under tests.
Finally, it’s worth it. It’s damn worth it. I’ve never written such beautiful or simple code as I do when I write tests first. But code aesthetics is a nothing phrase to most managers and business men. Luckily, along with writing nice code I find I write code that catches bugs more easily (at this stage each bug is usually a situation where I didn’t think to put a test case in), code that’s easier to maintain and understand (easy to tell what something does and how it works when a test is written for it) and my favourite: it increases my productivity (I make it a point to end each of my coding sessions on a failing test. It’s lovely to just hit compile and see exactly what that next thing I need to do is. Straight back into it!)
Having decided on our testing system to use – cxxtest was the winner in the end – the next step was to set up a working template project structure so that new projects with tests included could be created quickly.
The examples for setting up cxxtest for Visual Studio included with the suite recommend using 3 different projects to get the tests running: one project to generate the tests, one to compile them, and one to run them.
This seemed like an inelegant solution to me, so I set about creating a better one, that would hopefully be more cross-platform compatible (as our build server will be an OSX machine).
The first step is to relegate all the application code (except the main function) to a static library. I’ve been told this is good practice for writing code under test anyway – separate the code that can be tested from the code that can’t by placing all the tested code into a separate library. So far it sounds like an ideal, as there’s certainly code in the game library that I can’t put under test anyway (e.g. the Run() function). It’s easy enough to create an empty static library project in Visual Studio.
The next step is to add the tests in. Personally, when a project is small I like to keep the tests in the same project as the classes being tested. That way the classes (ClassName.h, ClassName.cpp) are right next to the ClassName_Tests.h file. So I include the test files in the static library project. In a larger project, or if your personal preference is to keep the tests separate, it’s possible to put the test files into the Tests project instead.
Which brings us to the third step: a project to generate, compile and run the tests. The project file itself starts as an empty console application, including the appropriate cxxtest directories. Generating the tests is done using the testgen Python or Perl script included with cxxtest. I run this as a command under pre-build events, easily translatable into a makefile when necessary:
python C:\cxxtest\cxxtestgen.py –-runner=ParenPrinter --output=TestRunner.cpp ../*_Tests.h
I prefer to store the tests project in a subfolder (Tests) away from my main source code, you’ll need to modify the commands to fit your own directory structure. The really cool bit is that you can use the wildcard to include all the headers ending with _Tests.h in your test runner. Note: this essentially puts the code of every test into TestRunner.cpp. It makes it quite a large file, but you should never have to modify it because it’s auto-generated.
Once the TestRunner.cpp has been generated, compiling the tests is pretty straightforward. There’s no need to include your project’s source directory as an additional include, because cxxtest takes the relative location of the include files into account when generating the runner.
Finally, the tests are run as a Post-Build event with the command line
This is a macro directly to the TestRunner executable created by the compile step.
And that’s a simple but effective template for including and automatically generating and running cxxtest-based tests in a Visual Studio 2008 project. You may also want to include a project that implements its own main() function that then instances and calls the code you create in the static library. This App project is simple to create, but needs to ensure that it is including and linking to the source and output of the static library. Also, you need to make sure you set all your project’s dependencies up so that they compile in the right order.
For those who want to have a poke around with the template I’ve created, you can download it here: template.zip (includes the App project and an easily renameable static lib project)
Posted by Tatham
| Tagged: Agile
It’s a first step in starting to create software using Test-Driven Development – deciding on how you want to write the tests. Having decided that I wanted to give TDD a good ol’ fashioned college try for my next projects (still somewhat under wraps), I found myself faced with a plethora of testing suites for C++ that were – no offense to the authors, effort and massive amount of time that obviously went into them all – not very good.
Being used to the simplicity of writing tests in C# using NUnit, I think I was a bit spoiled. Having to derive classes from a test class, declare tests in a header then implement them in a source file, manually add tests to a runner, and implement my own main() function to create and run a test suite – and almost every testing system for C++ I looked at required me to do at least one of these – seems like a lot more effort and room for mistake than I wanted in my testing suite.
Noel Llopis gave an excellent run-down of available testing suites for C++ on his blog a while back – it’s a fantastic read and I recommend you look at it if you want a full discussion of the available options. Having read the article myself I ended up needing to decide between only two suites: cxxtest, and UnitTest++. The former ended up being the victor of the available suites in Noel’s blog – the latter was written by Noel to fill the absence of a suite he actually wanted to use. Both implement the kind of easy creation of tests that I’m looking for.
They have their differences though: cxxtest uses Python (or Perl) to create the actual test code, parsing the header files defining the tests to create the implementation of the tests themselves. This makes the tests easy to write (just a header file), but it requires having Python or Perl installed on the system and setting the project or makefile up to generate and run the tests.
UnitTest++ on the other hand uses macros: the tests are defined in a source file using the TEST(testName) macro, which contains enough magic to turn the test into legal C++ and automatically register it. Organising tests into fixtures is a little different, as it’s designed to make it easy to create reusable variables without requiring accessors on them, which overall makes them quicker to use than the member variables in cxxtest.
In the end I’ve ended up going with cxxtest, despite the advantages offered by UnitTest++. My main reasoning behind this is that cxxtest has been seen working on an OSX build server (like ours will be), and as far as I know UnitTest++ may not have been. If I’m proved wrong, I may end up switching. But for now, we’re going with cxxtest.
Posted by Tatham
| Tagged: Agile