- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
// write some comment
Admin
"fortunately" in JS/TS, the 'in' operator does NOT act as substring, it checks if a property named 'test' is present in 'user' if it is an object.
unfortunately, if user is not an object (i.e. is a string, number or boolean). it throws
Admin
Which also hilariously implies that there is an optionally-defined property "test" on the user object, which seems like an invitation for TS codegolf to me. Especially since we don't care what the actual value of "user.test" is.
Admin
Of course they first checked a "names generator" site first to be sure that no legitimate name contains the string test.
Admin
The test property of the user object is set basing on a cookie.
Admin
Yes, good documentation for the commit is important. Alas a short (recommended 40 characters or less) message is rarely sufficient. This is why using a system that Links to the work tracking system (Azure DevOps Board, Jira, others) provides a much better solution. This also provides the means of linking together commits that are in pursuit of a common goal even if they are not consecutive.
Admin
Telling the testing system to bypass parts of the code that are causing the test to fail seems to be missing the whole point. If the test of expected behaviour fails for your new code, FIX THE CODE. Only bypass the tests when it can not be fully automated, like testing user interaction.
Admin
I accidentally pressed enter and submitted the wtf form with incomplete information... The test property only exists in test accounts, it exists for when third party APIs have separate test and real endpoints, we route test accounts to the test endpoint. This is not the case for this commit, it's really bypassing a whole feature. That commit is extra fun because even when manually testing it would bypass that code and lead to different behavior.. A bug in that part of the code would be "fun" to reproduce.
Admin
This "fix" is as in veterinarian, not mechanic.
Admin
Weird, I didn't think VW programmed their diesel engine control in TypeScript!
Admin
Sounds like you don't have correctly separated test and production environments, since you should be getting the endpoint to use from configuration that changes depending on the environment.
In that case, the [REDACTED] who made the commit should be sent on mandatory training to learn what unit tests are for, and why you don't disable them if the test fails.
Which is why the (...) should go on training.
Admin
They changed the code not the automated tests. They should have fixed the tests though They only made sure the new code was not triggered by any of the existing tests probably rendering the tests more or less useless as they now test a code path that is not applied to a regular user.
So the wtf is not the commit message but the commit content
Admin
Correction: the big WTF is not the commit message but the commit content. The commit message is a small WTF because it's vague and, like bad comments, does not explain what the thing is for (i.e. it does not answer "why?").
But it is far and far and farther than that from the worst commit message I've ever seen:
That's it, just a dot.
Admin
If user is a string the code will throw, but if user is a regex it will pass (as js regexes have a test method)… I feel great WTF potential in this code!
Admin
That reminds me of the time I got fed up of empty commit messages appearing in our Subversion repository. I added a pre-commit hook to reject the commit if the message was blank, and since the main culprit was a dev called Dave, the error message that was reported back was "I'm sorry Dave, I'm afraid I can't do that".
Eventually, after he got the joke I changed it to explain why he couldn't do that.
Admin
The "test" here clearly refers to a user account that is used for testing the API by users. Devs can code their applications that use this API and run it locally or elsewhere while developing their code without affecting actual user data or have actual effects. This is used, for instance, when you code against a payment API so you don't have to buy your own products with a real credit card in order to make sure your code is correct. It has nothing to do with testing to make sure the code works on the side of the company developing the API but instead is used by their clients which have their own devs to test to make sure their code is correct.
It seems interspersing code with ifs to branch off the test accounts in the middle of the code base is a bad design decision, but it's not clear where this code is located. It, for instance, this code is found soon after the request comes in, it may well be the right place to do this branching.
So a test account is like a normal account that can be used to access the API except it doesn't have real world effects.