I’m not a fan of code coverage tools. To me, TDD is not about achieving 100% coverage, but about helping drive design. It might be an OK metric to run on a large team that is not sold on TDD to make sure things aren’t sliding, but I wouldn’t get anything from running it on my own code.

And guess what, if I did run it, I doubt my code coverage would be higher than 80%. There is some glue code that is more of a pain to test than any benefits I get from testing it. Same thing with some “leaf” code that nothing depends on it.

And, may I humbly suggest using Visual Assist X’s (X part is important) “rename” refactoring instead of “replace-in-files”, because it works like a charm. Also with “extract method”, “move implementation to source file” they also work good. Enough advertising for Visual Assist X.

Thanks for you reply

There are a handful of features I’d love to use from VA, but I need to turn the other features off. For some reason, they don’t give you the option to disable most features and only turn on a few!

I’d also be curious to find out how easy it would be to extend something like Scons to do asset building (with totally custom rules).

I remember reading Noel’s Games From Within series on build tools a while ago and the main detractive thing he had to say about Jam was regarding its complexity. Well, that and the fact that “…Jam is dead…”; hence also my interest in your comment about an avid developer community. Serrendipitously in the last couple of days I ran across mention of KJam. Don’t really know much about either (with respect to the latter other than the main site, I found this article which looks to be by an author) but it would be interesting to hear what an experienced Jam user has to say about it if you have an opinion.

By the way, best luck with “Power of Two”. You are really an inspiration for all indies.

I guess it depends on the kind of refactoring.  In C++, most of our ‘rename’ refactoring is done using VS2005′s built-in "replace in files" functionality.  Amazingly enough, this purely syntactic approach usually gets us about 90-95% of the way through it and leaves us with just a few corner cases that require manual attention.  I also use Visual Assist for simple refactorings.

For bigger semantic refactorings, we usually end up following a fairly simple two-step pattern:

1. Get the target code compiling.  Start at the area of code you want to change, make your change, and try to compile.  At least in our codebase, the compiler is great for telling us what we need to do next.  Depending on how fundamental the refactoring is (and some of them have been _very_ foundational), this can take a while.  When you’re done, the game at least compiles.

2.  Get the tests compiling.  Semantic refactorings almost always physically break tests.  This is where you get to see the effects of your refactoring, and how it can change your original physical design in ways you didn’t necessarily expect.

3.  Get the tests passing.  This one can take a while, and usually contains a bunch of "oh wow" moments, where you realize, inevitably, that your changes had ramifications that you didn’t even consider.  This phase usually involves refactoring your original refactoring into a more refined and informed expression of what you originally intended.

4.  Write new tests.  Often refactorings like this will introduce new code, or pulling out chunks of functionality into new modules.  I usually go back and retro-test these after the fact, just to keep the test coverage high.

Really though, it all boils down to the tests.  We’ve found that the two most useful purposes of having unit tests around are to help flesh out the design of a module, and to aid in refactorings.  It’s really hard to understand the ramifications of your changes in a large and complex system, and any help you can get that makes things more visible is 100% worth it.  At least to us, anyway!

-charles

Still, it’s nice to see you can now build the Engine and Game in less time than it previously took just for the game!

Let me try it right now for the heck of it… Yeah, it’s a bit faster, but not as much as I expected. Down to 30 seconds from 36 seconds. Definitely not worth it in this case, but I could see how it could make a big difference for some projects.

Actually, I just realized you were probably not suggesting creating one mega project, but simply turning on /MP on all the projects and disabling the project-level paralellism. Trying right now… 35 seconds. So your hunch was right. It’s a bit faster. And it would probably be significantly faster if the libraries were larger, but they’re pretty small. Still, I think I like it better with the /MP switch. It feels more "controlled" somehow to know that the compiler is doing a single library before moving to the next one.

And while I’m it, let me try the opposite: No /MP switch, but crank up the number of parallel project builds to 4. And the results are… 33 seconds.

Now, this is not a very good test case, because we have 16 smallish libraries, and one large game project. Still, considering that 30 seconds is probably the best possible paralellization, being at 33 with no extra effort is pretty good.

Jam does much the same thing, relying on timestamps rather than direct hashing, and runs like lightning. Null builds are immediate returns, partial builds are just plain snappy compared to Visual Studio. The upside: speed. Jam is FAST, free, cross platform and has an avid developer community. The build intelligence is built into the Jambase language base so everything is up for grabs. The downside: There are three versions of Jam out there (ftjam, classic Jam and Boost Jam) with little to differentiate them that anyone but the most super advanced user would ever care about (start with ftjam, it understands VC8 better). The Jamfile language is kinda funky and documentation is scattered over the web. Basic use is simple to start with but has subtleties that take time to fully Grok – its’ a Prolog-like declarative, Python-like functional, string-list based language. Once you do get it, it’s full steam ahead.

We use SCons on our projects at work, but at home I use Jam and have promised myself never to use Make again. It’s great to be able to list a bunch of .cpp files and ask the build system to “go make a SharedLibrary() out of these”, have it find the interdependencies automatically and have the build script work on multiple platforms without any rewriting on your part.