Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
AmyShackles4234218dIs there some shared state that could be modified between tests that put the state of the application in a different one than expected? Is there a connection being closed that should stay open? An IO block?
Man. This sounds tough. Keep pushing though!
@OmerFlame Depends on the language.
I’m feeling chatty, so. Let’s go!
In some languages, constants aren’t constant. They’re just sugar, and it’s dumb. In Ruby, it’s a bit of both? You can redefine them, but (usually) not directly. It takes some effort, but it’s easier in specs for whatever reason. Also, changing their values almost always generates a warning. (I can think of one instance where it doesn’t — black `eval` magic)
In this case the constant is a whitelist. Most of the specs could be written to work without changing the whitelist, but that’s how they are 🤷🏻♀️. Some, like checking the error handling around when the whitelist itself is empty, require changing the constant.
The issue was that some of the tests were mutating the whitelist without restoring it afterwards. Slow to find, easy to fix. I also changed the new specs to set the whitelist to what they expect prior to running so they won’t be intermittent again.
Done and done.
@OmerFlame As in “syntactic sugar” — variations in syntax that makes the language more pleasant to use or increases readability, but (usually) doesn’t confer any additional functionality.
`foo if x`
`bar If y`
Functionally identical, but the latter can make things easier to read. (Pardon if that’s super obvious; just wanted to be clear! 😊)
I also refer to wrappers as “sugar” because they make things easier and more pleasant, but they usually also confer some additional functionality like error handling.
In Ruby’s case, constants do add some functionality in the form of exceptions/warnings when changing them, and the interpreter knows it’s a constant simply because of their case. But in the end, they are just vars like any other. That’s why i called them a bit of both.
@Wisecrack I’ve got another for you:
Smarter updating of Apple and Google wallets. They only update when specific columns change, and merchants can define which ones they care about.
The code works perfectly on Apple wallets, but not Google wallets. for google, they always update, no matter what.
They both use the exact same code. I had three other engineers look through the code, and everything looks solid.
Works on my machine. Works in specs. I wrote specs specifically for the misbehavior and related cases, and they all pass. Doesn’t work on staging or any QA/test environment, or on the prod clone with test data. We’re all stumped.
The cause is in some abstracted magic that compares current and previous values to see if a virtual column has changed. The previous values are never getting populated (or maybe persisted). I’ll know more when I delve into it.
Turns out QA missed this edge case on Apple wallets, and it does in fact happen with both. 🤦🏻♀️