Anyways, I haven’t really felt the need to use mocks yet since my project is small and pretty simple, and using full objects is fast enough and I don’t mind repeating tests by using non-mocked dependencies. I was hoping you could give me advice by answering a few questions about your mock example:

First off it seems like counting internal function calls on objects is just repeating the code you are about to write. If you are checking getEntityInfoCallCount to be a certain number you are just saying in your implementation you should be calling the dictionary GetEntityInfo method that many times. It seems strange that one of the requirements for CreateGameEntityCallsCreateMeshForEachMesh succeeding is to only call GetEntityInfo once, since it seems like an implementation detail that doesn’t really indicate whether or not CreateGameEntity is really functioning properly. For example, if you later wrote another part of the entity factory where you create a physics asset for the game entity, you might call GetEntityInfo again to check how many physics assets you need to make (of course you should probably cache it, but it doesn’t seem like grounds for test failure). Is it a good idea to have your tests tightly coupled with implementation details? I’ve personally been writing unit tests that check for correctness as much as possible, and implementation details as little as possible.

Second, would you recommend strictly avoiding repeating tests in favor of using mocks? So far I haven’t really been avoiding that since the only downfalls I can think of are the increased test duration, increased setup time for a test, and larger number of test failures when you break an object. The test duration could probably hurt for a larger project running 10,000+ tests, or if the operation is slow (e.g. networking, file-io, etc), but it hasn’t been an issue for my one person project. The setup time can be offset by using fixtures to repeat the work of creating your objects, so long as you’re not using a slow operation (which would basically be the same as increasing test duration). The larger number of test failures could be slightly more time consuming to track down the root of the problem, but if you see 20 tests that reference meshes failing, you can go check your mesh factory test, and see the problem right there.

The first big benefit that I feel like I’m getting by doing the repeated tests is that I know I’m using the object in the same way that the game will be using it, so I’m more likely to find crashes that my initial tests didn’t account for. Maybe this is where I should be using functional tests? The second big benefit for me is being able to write the test exactly how I intend the object to be used. If I have too many mock objects, it seems like it clouds up unit tests as documentation of how the code should be used and what to expect from it.

Anyways, any thoughts you have would be a great help! Thanks!

“At that point, your code design is going to start looking more like a tangled web of objects communicating in complex ways, rather than simple functions without any dependencies. You might have saved some typing time, but at what price!”

It’s a sliding scale, in my opinion. The more roles and responsibilities you give to one type, the more can go wrong with it and the harder it is to test in isolation (or indeed to swap out different parts of its logic). If a single method does 3 complicated things, it may well be advantageous to split those three things into 3 different types with distinct responsibilities. These can be tested in isolation.

To me, when this is done well, it doesn’t feel like ‘a tangled web of objects’ because the interactions are typically very simple. You can immediately concentrate on the interface rather than the implementation. The only caveat is that the object graph is more complex to wire up and, depending on the language & tooling used, I concede this can be a big obstruction.

With C#, creating new types, extracting interfaces and navigating inheritance hierarchies is really easy thanks to tooling (ReSharper is amazing for code gen / refactoring / navigation) and the lack of header files, but even then there is a limit where numerous discrete types being to lose their allure. As the article says, if you take the single responsibility principle to extremes, things gets silly very quickly

The flip side to my c# love-in is that I recently started writing some C++ again and the IDE / refactoring / code navigation support (VAX included) is not on the same level compared to what I’ve grown accustomed to in the .NET world. I’m also used to using an IoC container to manage the object graph’s construction and, as far as I’m aware, there is no comparable construct in C++ due to the lack of reflection.

Having to write code like var blah = new Blah(new Wargh(), new OhNo(5, 10)), new Aaaaaaaaaaaaah()) etc. is really, really sucky and brittle. I’ve seen IoC container versus manual wiring in the same codebase and the manual wiring was a terrible maintenance overhead, as altering one or two constructors / types could require changes in many places. As a result, it seems there’s pretty much no option but to back off on the object graph complexity in C++.

That aside, I do sometimes use two or three (hardly ever more than that) check statements per TDD test when they’re just clearly testing different aspects of the same thing. The name of the test plus the check statement always make it really obvious what went wrong. It comes down to personal perference I suppose.

I would also like to point out the a Mock is a Fake so to talk about Mocks and Fakes does not make much sense, on the other hand a Stub and a Mock are different whilst they are still both fakes.