You’ve either done it yourself or you’ve seen others done it. Uncommented a whole test, a test fixture or maybe an entire file.
I know, it’s so easy to press Ctrl+A, Ctrl+K+C to uncomment everything. You’re probably changing an interface. Most likely, the methods that are tested don’t exist anymore in the form in which the tests calls them. You probably just click and drag the mouse and comment out a block. But please, be careful. I’ve seen a lot of examples where an entire file ended up commented out for months. Only to turn out to be crucial, because it tested a very important scenario.
First and foremost, if you are refactoring, please look at the tests as if it’s production code. You are best off getting the tests to compile, even if that takes extra time and you’d rather pull the main code back on its feet before you worry about the tests. Be aware that the “it takes extra time…” is a fallacy. It just takes time. It’s part of your job. It’s not less important than the rest of the code. Probably the contrary. You’re better off keeping the tests compiling all the time.
But if you must, please, don’t comment out a whole test or whole fixture. If you must, then do it like this, instead:
public void SomeMethod_SomeCondition_ShouldDoSomething()
// SystemUnderTest sut = new SystemUnderTest();
Assert.Fail("TODO: Fix this test");
That way, at least your test suite will alert you that there are a couple of tests you still need to fix. And you won’t have a colleague pointing out to you that that commit you did two months ago effectively deleted some really important tests…
Someone has been using EJS (or similar) and forgot to add an = sign
The WordPress plugin I wrote, Category Posts in Custom Menu, supports custom extensions. Recently, I wrote an extension for someone who wanted to show all posts from some category, say “category A” that were ALSO in “category B” AND NOT in “category C”. So, I helped out (coding, yay) figuring it would give me an idea of whether the extension possibilities I created make sense.
If you’re interested, you can now find all the source code at GitHub. This extension was aptly (ahem) named “cpcm-and-and-not-extension”.
#warning This is going to be a nitpicky post.
There was once a developer who marked his code with TODO’s.
// TODO does not handle case X
public void Handle()
// TODO clean this up
var ugly = ...
// TODO re-enable after Y is implemented
// if (bla)
Another developer used warnings.
#warning still have to write test for this
case a: i = 4; break;
case c: i = 1;
default: throw new InvalidOperationException();
I’m writing this blog post to illustrate subtle but significant differences between four mechanisms that can be used for a shared goal: To mark what still needs to be done.
“Man, I just love unit tests, I’ve just been able to make a bunch of changes to the way something works, and then was able to confirm I hadn’t broken anything by running the test over it again…” — http://stackoverflow.com/a/67500
The benefits of unit testing are well known, as are the many reasons that are offered when asked “Why don’t you do it?”. The arguments I hear over and over are:
- “It takes too much time.”
- “Our code isn’t suitable for unit testing.”
I’ve discussed unit testing with many people in the past years and at some point, I discovered one of the main reasons behind the arguments that were actually offered. We human beings find it much easier to say “It’s not possible”, “It’s too expensive”, “I don’t want to” or “I won’t start doing this until I’ve seen it work” (this one I encounter surprisingly often and makes me smile nowadays) than to admit:
On holiday this year, same as last year, I downloaded a few puzzle games for my phone. One of them was Einstein Grid Master by Kerelize. (You can find it in the Android Play Store.)
The game consists of a 10 by 10 grid in which the user clicks on various cells to place the next digit, starting at 1. The goal of the game is to fill the entire grid with numbers 1 through 100. However, you can’t just place the digits anywhere, you have limited possibilities to place the next digit.
After playing for a while, I decided that instead of endlessly trying various possibilities, I’d write a little program to do this for me 🙂
The program is a little bare bones and only does some basic checking to determine whether continuing the chosen path has a possibility of coming to a solution, but it was fun to do anyway. On to the next puzzle I’m too lazy to solve by hand 😉
A year or so ago, my partner and I said to eachother “Wouldn’t it be cool to create a LED wall for our living room?”. We then set about to buy an Arduino and some required components for the first prototype. It took a while for us to actually get started, but my phone tells me that on the 7th of June I sent my technogeeky friends a photo over WhatsApp of my breadboard experiment:
Frankly, I’m surprised that I can’t find more blog posts on this topic.
I can’t imagine that I’m the only software engineer who has encountered dependency management of the form “it’s somewhere on the K: drive”. And yet, when I search online, I can’t find anyone griping about this. All I can find is this one blog post by Sonatype that goes on to advertise their Nexus repository manager.
In this case, we use environment variables for all our builds.. or so I thought. Last week, I encountered one project that was making an exception and doing its own thing: It was explicitly calling a tool on the K: drive and linking against libraries on that drive. Not only that, it didn’t use environment variables but hardcoded the path to the network drive in the build script and VS project settings.
I prefer expressing the difference between project a solution owns and projects it does not own (dependencies) with the help of Visual Studio’s solution folders. It’s a trick I didn’t come up with myself, I’ve deftly stolen it from a former colleague.
There are four categories:
- The main project (in most cases a library or application)
- Other projects the solution owns, that the main project depends on.
- Test projects
- Dependencies: projects the solution does not own
For a little dummy project like this it seems like a lot of overhead, but I’ve experienced that the list of dependencies can become quite large and the number of test projects grows with the number of projects under 1. and 2. What I like most about this approach, is that if you consistently apply this across your solutions, you always know what to expect when opening a solution; at a glance you’ll see what it’s all about. All in all I find it worthwhile to apply this grouping.
A issue that occurred has been fixed with some help from other plugin developers. This problem was that WordPress doesn’t have a hook to add fields to the Appearance > Menus page. I used to fix this by just overriding the function that created this page, but this way of working means more risk of conflicts with WordPress (updates / changes to the markup) and other plugins (only one can ultimately create the HTML that way). Thanks to the plugin author of Max Mega Menu, who pointed out a workaround other plugin developers have been using, this is no longer such an issue. I intended to implement their suggestion for some time now, and today I got around to it.
In the next release, my plugin now supports the wp_nav_menu_item_custom_fields hook and should be compatible with other plugins. See original support question here: Is there any way to use this with Max Mega Menus?
Those who need this functionality right away can grab the latest development version at the plugin page on WordPress.org