Having fun while testing RevDeBug
Dealing with the mundane in your day to day job.
A few years ago, Jeff Weiner, CEO of LinkedIn, shared an article pointing out the importance of knowing how to have fun while working. Yet, how do you apply fun to the testing of a dev tool?
When I was on a quest for a complex project on how to test how RevDeBug affects performance, I immediately thought about porn, I mean games. Yes, games are what I said. Don’t judge. What could be better than a game you have happy memories of?
Enter OpenRa, an open-source port of RedAlert. Its developers have done a darn admirable job and running the project from sources, is as quick as downloading and running a premade script that downloads all needed dependencies, Bob’s your uncle, and you’re good to go.
The first test run ended pretty fast. It turned out that the game generates so much data, that recording everything with RevDeBug caused severe performance issues. I wasn’t worried at all, I was more or less expecting it. That was an excellent opportunity to check if our blacklisting mechanisms still work. Blacklisting allows you to decide which parts of code are excluded from being recorded. It’s handy when you want to limit the size of your recording.
I started by adding an empty “ra.rdbignore” file to my project. With the rdbignore file, you can exclude whole directories or data from the recording. You can add as many files as you want with the rdbignore extension, have their build action set to “Additional Files” in the properties window in Visual Studio.
As I was hoping to inspect the game’s logic, the first to ignore were folders; Sound, Graphics, FileFormats, FileSystem, Primitives, Map, Support and Network. I wasn’t particularly interested in those things, and they for sure generate a shit ton of data. Then I added particular files for math operations i.e. classes for evaluating angles, offsets, distances, etc: WVec.cs CVec.cs WAngle.cs WRot.cs WDist.cs, Extension methods: StreamExts.cs, Exts.cs and classes with heavy calculations: Renderer, Sync, Pos, Shroud. At the end my RA.rdbignore file looked like this:
After that, the game was playable, but I wanted to improve performance even more, and it still looked like there was too much chaff in the recording. This time, however, I couldn’t exclude whole files because they had at least some valuable information in them. The tool I needed was more of a scalpel or #region NoTimeTravel. Thanks to this NoTimeTravel option, you can tell RevDeBug not to record specific lines of code in your class. To use it, surround the code with the “#region NoTimeTravel” directive.
I used it on methods that do a lot of math e.g., hash calculations, renderers, and some support operations during ticks that are executed 60 times per second.
Now I can comfortably play Red Alert while recording the game’s logic with RevDeBug. I started the first alliance mission, but it turned out that saving Einstein isn’t as easy as I remembered, and I saw a failure screen pretty fast. So I thought, “Okay, let’s stop for a second and test if RevDeBug’s search works fine” And sure enough with a search, you can easily find any value that was recorded. Just hit the magnifier icon on the RevDeBug toolbar and type what you’re looking for. I typed “Tanya” because I remember her name from mission briefing. After a few seconds, I got my results and was able to see all the objectives and even more in the code:
After confirming that it worked as expected, I confidently returned to saving Einstein.
OpenRA permanently settled games as part of your testing projects and provided fun in doing what sometimes can feel mundane.
If you want to check out how OpenRA works with RevDeBug for yourself, you can try it on your own by cloning our OpenRA fork on GitHub and the newest version of RevDeBug the newest version of RevDeBug. Have fun!