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 testing of a dev tool?
When I was on a quest for a complex project on how totest just how RevDeBug affects performance, I immediately thought about porn, I mean games. Yes, games is what I meant. Don’t judge. What could be a 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 serious performance issues. I wasn’t worried at all, I was more or less expecting it. That was a great opportunity to check if our blacklisting mechanisms still works. Blacklisting allows you to decide, which parts of code are excluded from being recorded. It’s very effective when you want to limit the size of your recording.
I started with adding an empty “ra.rdbignore” file to my project. With the rdbignore file you can exclude whole directories or files from the recording. You can add as many files as you want with the rdbignore extension, just have their build action set to “Additional Files” in 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, just surround the code with “#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 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!