Yesterday was another one of those little lessons in Unit Testing.
In one of the applications I work on there is a lot of clever string manipulation in order to derive intelligence from the data contained in the string. Lots of array generation and scoring of individual elements within those arrays and so on. The problem was during debugging within Visual Studio I was getting the desired output from the process I was unit testing. All good. The problem was as soon as that same test hit the build server it was failing.
I spent quite a while trying to track down what might be happening. Since it was all geared around string manipulation I was looking for something related to any string comparison code I’ve written. Is this a culture issue? Am I making some obvious mistake with how some of the arrays are being treated? Round and round looking at the same code trying to figure it out.
Those moments when your “coding cool” starts to ebb away and morph into pure frustration at mild annoyances.
After about an hour (a few cups of coffee) I suddenly realised what the problem was.
Since I was obviously debugging within Visual Studio this making use of the application in the context of which I have been using the application to debug. Meaning that the user configurable options that I have set were being used. This was not the case on the build server as the application hadn’t ever been run on that machine and certainly not in the context of the build servers build process. So the two were not matching in configuration.
The setting in question allows the user to switch on deeper “fuzzy matching” on the string manipulation code. If the code runs through it’s normal matching process and still hasn’t found an obvious match if this “Use Fuzzy Matching” item is turned out another set of rules come into play and the system then attempts to make a fuzzy “best guess” which, obviously, will create a different result.
So, todays lesson is when there are user configs involved in the code being tested, make sure you explicitly set these in each unit test!
Yesterday was another one of those little lessons in Unit Testing.
In one of the applications I work on there is a lot of clever string manipulation in order to derive intelligence from the data contained in the string. Lots of array generation and scoring of individual elements within those arrays and so on. The problem was during debugging within Visual Studio I was getting the desired output from the process I was unit testing. All good. The problem was as soon as that same test hit the build server it was failing.
I spent quite a while trying to track down what might be happening. Since it was all geared around string manipulation I was looking for something related to any string comparison code I’ve written. Is this a culture issue? Am I making some obvious mistake with how some of the arrays are being treated? Round and round looking at the same code trying to figure it out.
Those moments when your “coding cool” starts to ebb away and morph into pure frustration at mild annoyances.
After about an hour (a few cups of coffee) I suddenly realised what the problem was.
Since I was obviously debugging within Visual Studio this making use of the application in the context of which I have been using the application to debug. Meaning that the user configurable options that I have set were being used. This was not the case on the build server as the application hadn’t ever been run on that machine and certainly not in the context of the build servers build process. So the two were not matching in configuration.
The setting in question allows the user to switch on deeper “fuzzy matching” on the string manipulation code. If the code runs through it’s normal matching process and still hasn’t found an obvious match if this “Use Fuzzy Matching” item is turned out another set of rules come into play and the system then attempts to make a fuzzy “best guess” which, obviously, will create a different result.
So, todays lesson is when there are user configs involved in the code being tested, make sure you explicitly set these in each unit test!