One thing that should be clear and is important to stress is that TDD is not just writing unit tests. TDD is a development methodology, not a testing one. That’s why TDD’s benefits deal with better code design and structure, ease of refacto…

Game Developers Conference 2006 closed its doors last week. Soon or later most of the presentations will be published in the official site. While that comes, I will be posting here links to papers and presentations (only about programming) made public…

So after another trip to San Jose, I must say that the sessions were hit and miss.

Noel and I differ a bit on mocks. I use them quite a bit in the project I’m working on. I think part of the reason is that mocks are much easier to create in UnrealScript than in C++. Extracting an interface, renaming everything and worrying about virtual function overhead can put a damper on the whole process. Also, as Noel mentions, if you design your code to be horizontal you need them less.

The do make many tests much simpler and orthagonal

the bmock library is not published yet. In fact it was initially developed for internal use only, but then I realised it might be useful for a wider audience. I will try to put it somewhere at sourceforge when I come back from my recent business trip (in two weeks). If you want to take a look at its documentation gmail me a line using my first name, dot, last name as an address (a naive anti-spam measure).

Now with regard to your comment about mocks and flat object structure I think I see where does the argument lay. In OO we indeed have a best practices recommendation to avoid deep inheritance hierarchy since it typically leads to a very fragile and overcomplicated structure. I’m not sure it’s the same with regrad to an object composition structue, which could be quite deep. The very concept of cohesion and delegation assumes that every object concentrates on its own responsibilities and delegates the rest to other objects. So inter-object communication and thus a need for mocks is supposed to be a norm rather than an exception. Not useing mocks would lead to more complex tests and fixtures.

Asher

I’ve been looking at various software development methodologies lately and I’ve found some pretty interesting blogs on one type that is very exciting.

Titus suggested I post some of the links I keep sending him, so here they are

I love to find information that backs up my belief that agile development practices are gaining wider acceptance, such as this article describing how to do TDD game programming in C++.

This Test-Driven Development (TDD) paper was presented yesterday at GDC (the Game Developers Conference). Not that I was present to see it…

That’s actually really important, because it allows us to run $(TargetPath) in the postbuild step and have the executable return the number of failed tests. So whenever any test fails, the whole build fails. Not only does Visual Studio indicate this in the output log, but it will also fail any automated builds in your build server without having to do any extra checks.

I agree that mocks have a place in testing and they’re a good, necessary technique. But I still think that if most tests are using mocks, it’s an indication of code that is not modular enough. One of the great side effects of TDD is that it really encourages you to have a flat architecture, with many leaf nodes. Using mocks all the time would indicate many dependencies and not many leaf nodes.

Yes, Visual Studio ignores error codes. It flags errors by parsing the output window! You have to format your message like so:

std::cout << “\n” << file << “(” << line << “) : error: ” << message << std::endl;

Then it will find it and jump to file and line when you select it.

a good article, I really enjoyed reading it. There are too many things I fully agree with to be mentioned in this short comment. Let me highlight a point where I hold a different opinion, namely using mocks for TDD.

In “Object interactions” you wrote: “using mocks frequently could be an indication that the code relies too much on heavy objects with complex interactions …” I do not think it’s true. Even if you have “many, loosely coupled, simpler objects” you need somehow to break dependencies in order to test them in isolation. You may use fakes as Michael Feathers suggests, but manual creation of fakes could very soon turn to be too burdensome. You also need something to deal with system API as you described in “Graphics, middleware, and other AIPs”.

In fact there many system things you would like to have a control over within your test environment: random numbers, clock, file system, communication, even threads. Having a good mocks library would help here drammatically.

I think the problem is that for C++ we do not have one. Mockpp, at least in my opinion, is a too straitforward port from Java and C#, and is not suitable for C/C++ (similar to what happend with CppUnit).

For that reason I developed a small library, called bmock, which is more or less in line with JMock and NMock, but realistically takes into account C/C++ specifics.

With bmock a mock version of a function is just a simple IDL-like annotation: BMOCK_FUNCTION(int,f,1,(IN(int,x))). The rest is done automatically. Setting expectations is also very simple: BMOCK_EXPECT_RETURN(12,f(35));

The bmock library is built on the top of the C++ Boost library and uses its Boost.Test diagnostics (could be easily integrated with any other unit testing framework – I did it for CUnit!).