Being a Test-Driven Developer is a choice

On October 31, 2013, in idevblogaday, by Steffen Itterheim

This is my coming out: I’m not a test-driven developer. I have stopped trying to force it onto myself.

Yet I do test.

TDD never seemed to work very well for me personally. As a consequence the process never took hold in my habits of writing code, it did not prove itself as the uber-strategy to advancing to the next engineering level.

It took me a while to free myself of thinking that by not following TDD, that I am somehow an undergraduate software engineer. Or worse. As is sometimes implied by more religiously test-driven developers.

Eventually I realized that test-driven development is a thing that you’re born to love, or you aren’t. A process that works better or worse depending on personal habits, circumstances and environment – in that sense I now regard test-driven development along other relatively subjective and debated processes, like pair programming (XP).

Moreover, like pair programming, the minimum requirement is two programmers. If there are only two programmers in your team, it’s a freakin’ waste of time to do pair-programming round the clock. In the same light my experience with TDD is specifically in environments where I was/am the sole programmer, perhaps only occasionally sharing code development with one or two other developers at most.

This is where TDD’s proposed benefits lose a lot of their weight, while its drawbacks are more pronounced, and a more “agile” process works just as well for sole developers and tiny teams.

TDD is a personal preference

Unit testing is a tool used in test-driven development. If you don’t “test first” and then write the class’ code and then refactor, you aren’t doing test-driven development, you are testing. On the other hand, you can do just that without following the formal TDD process.

In test-driven development, the tests are written first. They are made to fail because the class they test hasn’t been written yet, it’s only a stub. Therefore all tests initially fail. Then you write code. Then you test and verify. Then you refactor. Then you test and verify again.

TDD is a fairly rigorous, rinse and repeat kind of process. It formalizes the process of writing code. It sometimes feels great, other times it feels terribly constrictive. Unfortunately TDD is not someting that you can do on and off, and still expect it to be very effective. Which means you have to be a rigorously test-driven developer. That might also explain why some developers are quite religious about TDD.

I wager that TDD is significantly harder to subscribe to for certain developer archetypes than others. It makes little sense to force it on developers. A lot of the process has to do with personal preference and a certain enlightened feeling that comes when applying and succeeding with it. Likewise, others may still be in shock after weeks and may forever struggle to adapt.

What is often forgotten when adapting TDD is to actually measure key metrics for the team and individual programmer, both before and after – for some teams/individuals the benefits may be tremendous, for others it may reveal fewer defects but also slower development. Then what remains is a tradeoff: do you prefer fewer defects or faster development? This is a valid question in any product development.

It should also be considered that it takes significantly greater effort for an experienced software engineer to change his or her personal process of developing code than it is for a student. Talk about teaching old dogs new tricks. The students are also more likely to find great rewards in test-driven development as TDD encourages them to learn and experience many software engineering principles.

Undeniably, test-driven development has benefits even for experienced developers. But since I’m talking about TDD specifically for sole developers and fairly small projects, then TDD is simply much less effective in my experience. A more informal process works just as well.

TDD benefits are generally overrated

There are benefits and drawbacks to TDD. Most remain inconclusive and subjective, only few have been measured in some very narrow-focused case studies (here and here).

Continue reading »

Tagged with:  

I frequently see questions like Should I use game engine A or game engine B? Sometimes the question is slightly more specific like Is game engine A right for this game?

These questions are not unlike giving a list of features or requirements and then asking Is potential partner A better for me than potential partner B? And some are closer to asking the general public a very subjective question that requires intimate knowledge about the person who is asking: With whom will I have better sex, A or B?

Well … while there’s a checklist of features that A and B may or may not have that might have some influence on the decision, more often than not your choice depends a whole lot more on whether it just feels right.

You may feel attracted to A because A is so reasonable and the support is responsive and helpful, or you may simply find yourself attracted to how B is open to everything and free of charge. You may also find that despite A or B lacking a specific feature you crave, other aspects that you didn’t even think of more than make up for it. Features aren’t everything, more important is the spirit and ease of use.

Not uncommonly a fully featured game engine (or partner) with all bells and whistles may turn out to have a really steep learning curve, many restrictions, limitations, policies, quirks while “free” may cost you a lot more than you bargained for.

Following is my game engine dating advice that you can take to places like to make your pick. These are the things that I consider the most important when choosing a game engine for small projects, and that is irregardless of the type of game I might want to develop.

Continue reading »

I made a few additions to the Xcode Tutorial and the cocos2d FAQ which are based on user questions and concerns.

Xcode Project Tutorial: How to integrate Chipmunk SpaceManager

How to update the cocos2d-iphone code in a project created with a cocos2d Project Template? (Theory & Advice)

How to fix common Box2d compile errors? (must compile using C++)

How to fix common Chipmunk compile errors? (does not compile with C++ code)

How to draw an endlessly repeating Parallax Background? (very simple, very effective)

On Searching the Tutorial & FAQs

I’m still trying to get the search function on the Tutorial and FAQ pages fixed. Currently it works for the Xcode Tutorial only but other search result links may simply show an Error. I’ll try to get this fixed as fast as i can and i’m getting very helpful support from the folks at ScreenSteps Live so i’m hopeful.

Please also note that the search box in the navigation panel doesn’t search the FAQ and Tutorials, just the blog and pages.

Tagged with: