On Programming

I have made an observation the other day about a curious correlation between Test Driven Development (TDD) and what is nowadays called the “Law of Attraction”. This law roughly states that you will attract into your life whatever things or circumstances you repeatedly think about and desire. While I don’t agree with how this concept is very aggressively marketed today, I tend to believe that it works.

A key element in the law of attraction is faith. If you repeatedly think about something that you would like to have (or have happen), and you have absolute faith in getting it, you will get it, the law says. This technique can be put to use most efficiently by repeatedly thinking about the desired thing as if it would already exist (thereby exercising absolute faith). For example (modern examples for this law seem to be notoriously monetary), instead of saying, “I have faith that I will have a million dollars”, one would rather say, “I have a million dollars”, ideally repeating this several times a day.

By stating the object of our desire as if it were already a reality, we create a strong tension between the current reality (not having whatever we desire) and the desired reality. Our persistent and absolute faith then compels us to take action that will resolve this tension, by moving us towards the reality that we desire. Depending on your believe system you might also say that this action is guided by god, the universe, your subconscious mind, the divine, your muse, inspiration, etc.

If you are a programmer, and you are still reading, congratulations! Because now, let’s think about Test Driven Development, where usually one goes about writing a test first, that is, before the code that would make it pass even exists. So by writing this test, we pretend that the code that will make it pass (or even compile) is already there. Our test talks about the desired object, the code, as if it were already written. In other words, we express absolute faith that the code will eventually be written. In fact, our failing test starts to attract the code that will make it pass.
Now, after we clearly stated what we want, we run our compiler and/or test framework and immediately get in touch with the current reality. The test will fail. Since we have a desire to make it pass, and absolute faith that we can make it pass, the tension between the current reality and our desired reality will compel us to write the code necessary to make the test pass. Every test becomes a mini-fulfillment of a clearly stated desire. That might just be the reason why writing failing tests and making them pass is so satisfying.

Yesterday I listened to ‘Burning Down the House: Game Developers Rant’, available here. It is the recording of a panel that was held last year at the Game Developers Conference and it became very popular, because big game industry names were cursing our industry, and they also used “fuck” a lot, apparently previously being encouraged to do so. So, I decided, to write a rant myself. Keeping with tradition, it will contain the occasional swearword, so your discretion is advised.

Read the rest of this entry »

I recently implemented “picking” in the publicly available parts of the Doom 3 engine. Picking in 3D games (or applications) means that the mouse cursor position is mapped to the 3D world in such a way that the mouse can be used to “pick” up objects in 3D space. In this post I would like to describe how I used testing in implementing this technique, by first implementing a “spike” solution with visual testing, and then using data from this solution to implement a piece of code that is fully tested without manual intervention. This is an exercise in arriving from an unreliable testing method, that is, looking at the screen, to a reliable one, using data that a machine can process automatically. I briefly touched on the same topic here.

Read the rest of this entry »

Allow me to gleefully report that I have integrated my unit testing framework into the Doom 3 engine.

I have previously used this framework to run unit tests via a simple text interface. Tests are easily defined using a simple set of macros and automatically enumerated. Now, whenever my modified version of Doom 3 starts up, it will do the same, it will enumerate tests wherever they have been implemented in the code, and I can operate those tests via the in-game console. Have a look:

Now, why did I do this? I will of course also have a seperate program with a lot of unit tests, as I develop my software test by test. However, I will want to write tests that will need the game running in some stage, and part of the beauty of all id Software engines is that they make it extremely easy to hook in any kind of custom code that is readily executable in the game at any time, via custom console commands, thus opening up an extensible command line interface to the running game. And so I not only have the environment in which to run my tests, it also hosts them and provides an interface to them. That, I think, is quite beautiful.

I am not working for Id Software, in case you were wondering. I am using the publicly available tools and source code for modifying the original game.

When looking for X-Macros on Google, the only reference I came across was this one (ddj.com), which is also the place where I happened across X-Macros by accident (in the printed version of the magazine). I have since put them to great use in production code. What are X-Macros? They are basically a clever way to avoid code duplication, using the C/C++ preprocessor. They come in very handy whenever you would normally need to hunt down and hand-edit multiple places in your code after expanding or modifying some lower level layer which this code depends upon. Let’s look at some examples to find out what X-Macros might be able to do for you.

Read the rest of this entry »