Regex
I use a lot of regex. I’ve written parses and tokenisers for a wide range of DSL’s and data formats. So one day, I reached for my Regex-fu to validate a credit card number, and it was gone. Like superman finding he suddenly couldn’t fly, I found myself glued to the earth, taking the stairs…
What’s going on?
Does this look right to you? Because it sure didn’t look right to me…. and I spent a long time staring at it.
What’s really going on?
So… what is this dastardly bug that has cropped up? Why are my tests failing, and how did I get there? Well… I started with the simplest scenarios. This seems like a solid start right? We’re all good?
That all works right? Regex magic all good. But when I added the new scenario above, it failed. And this confused me, because I knew it worked on the simpler scenario, that assumption was now in my white list. My test pass, they prove the regex is correct, but a new scenario failes then it has to be a bug, right?
Well… not quite. See… here’s the thing…
Regex… has TWO STRING PARAMETERS. Do you know what happens if you put them in the wrong order? It don’t work right. So what was my assumption? That the Regex pattern was on the left.
But… why didn’t we catch that? Surely the tests would have picked up that the Regex and the check are in the wrong order? We validate both the positive and the negative… But…
This check string matches the valid pattern, and the pattern matches the valid check string, so it works either way round.
So yeah, assumptions creep in, and you forget to go back to basics and re-validate.
Sick Note
I totally want to play my sick note card here. I had food poisoning and spent hours peering through heavy brain fog.
But I don’t really have any excuse… this is just one of those experiences that keeps you humble.
So in a note to other devs… sick or not, check your bloody assumptions before you do something really stupid like filing a report for a non existant bug.
Credit
Header Image by OpenClipart-Vectors from Pixabay
