- 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
Eh, I don't really see a problem here. Perhaps it's very awkward to determine the number in runtime, and the number of archs probably do not change very often. Add a proper comment that says this needs to be updated whenever an arch is added/removed and you are good to go.
Admin
Not really a WTF, if someone ask you to implement such a function, how are you supposed to know the magic number?
Admin
Admin
Well, since tests are failing, there must be some way to see if the number is right. If they couldn't make a practical function, they should have at least made a test that fails with a clear message about what the actual problem is.
Admin
TRWTF is not having a test to assert that "7" is a valid architecture!
Admin
Seven architectures should be enough for anyone --- Steve Ballmer
Admin
Meh, if at the time it was written there were seven architectures to deal with and nothing on the horizon then as far as I'm concerned the coder gets the credit for putting the stub function in and not wasting time writing something that probably wouldn't have been properly tested anyway.
Admin
Dunno about that.
Let's say I'm a megacorp with a product that will be deployed across N architectures. (Or a minicorp that deploys across N flavours of Linux, for that matter).
In either case, I'm going to be building the latest version of the product for each of N architectures/flavours. Let's say I use Jenkins or the moral equivalent thereof.
First step in Jenkins would be to check the list of N. Oh look, N == 8. Set an environment variable for the testing environment.
Run all N builds.
Run the tests. Don't hard-code for get_num_archs. Set it to the environment variable.
Bit of a cock-up all round, this one, isn't it? Then again, it's not obvious why you would care about the cardinality of the set of architectures, rather than just running the test suite for each one.
Admin
I was assuming it was a simple cumulative thing. At this time we support seven architectures, so if you rock up with something that hasn't sorted out the bits and bobs for all seven, go back and see what you've forgotten.
So they should've done a simple if statement in which num_archs>7 spits out some error message saying "Hey guys, lets add the new stuff into the test system for this new one!". Doesn't matter what testing thingy they want to use, the logic is the same.
I assumed this was a quick pre-test check so you don't hammer through the tests for six architectures for hours before spitting out the "where's number seven?" error, and of course the absence of this check would mean testing for the 8th unknown architecture would simply be skipped unless someone took the time to check the documentation ..... we can infer from the article that such a thing doesn't exist or, if it does, it's nonsense or no-one is reading it.
Admin
Well, considering that (in my scenario) you have NxM customers for what you were building yesterday, where N is the cardinality for yesterday and M is the mean for customers per architecture (yes, not accurate, but still), I disagree with your approach.
Go ahead and build the bloody things, and test them. You already have customers to support.
Should N' be one or more less than N, you don't have a problem. Go ahead and build useless things. Test them.
Should N' be one or more greater than N, you have a problem. It isn't going to be helped in any way by this dreck. But it's minimised by the fact that this dreck doesn't stop you building and testing product for your pre-existing customers.
Sure, fire off an alert when N' is greater than N. Or even when it is less than N. But it's utterly absurd to configure a constant value into what is a DevOps/Management requirement.
Admin
Oh I don't disagree with it from that perspective .. we don't have the full picture. My comment was based on the assumption we have only 7 architectures to support and no current plans to add an 8th. As you say, we wouldn't release for only 5 or 6. Yeah, it still could be picked up dynamically, a bit lazy not to, but it's not going to change the fact that at the time it fails this is either someone pitching up with ain incomplete release or the script needs a new platform added in. I couldn't imagine that the testing was only "are there exactly seven architectures? Yes? that's good enough for me lets rumble along without delving any further. ". But then maybe that is it, that would be really dumb, but not the first time we've seen that sort of thing!.
Admin
The code base changed and a test failed because of the change. That is what you want to happen. Marlyn should be grateful, not annoyed.
If you're always expecting seven architectures, and get eight or six, the test should fail. If you're not going to hard-code "7" into the test code, where are you getting it from? If the number of architectures varies per branch, have a different version of the function on each branch - a pattern for managing platform-dependent code.
If the diagnostics are unclear, improve them. If this needs to be better documented, do that. But "a test failed because the thing it tests changed" is not a WTF. Why would you ever assume that the test code is bug-free?
Admin
WHen I said "Where are you going to get it [the number of architectures] from?" you can of course get it dynamically. But how does that help you? You're now just testing that the number of architectures is, er, the number of architectures, what I tend to call a TEST(1 == 1) kind of test. That, I presume, is NOT what this is supposed to test.