• Anon (unregistered)

    Testing for frist.

    Results are checked after the report is generated, pin for a future metting.

  • (nodebb)

    OK, so the team lead has a blonde moment, the developer explains, and the team lead realises his mistake. Doesn't, as such, sound like a WTF.

    The WTF, perhaps, is that the whole URL is configured in one piece, rather than being configured (?) as the path-on-the-host (which, it seems to me, really shouldn't change between environments, and probably shouldn't be configuration anyway) and the hostname, which should apply to all uses of any part of the API.

    Or maybe I've misunderstood how REST APIs work between test and production environments.

    In any event, the topic of why it failed is worth pursuing, but it isn't amenable to a unit test in the same way we usually think of unit tests.

  • (nodebb)

    I think the WTF is the slavish devotion to 100% test coverage. Or that's what it seemed like. The lead wanted a bug fix that didn't need a unit test to have one just because "muh policy" and didn't bother to consider why that policy may have actually been created in the first place.

  • MIKE (unregistered) in reply to Steve_The_Cynic

    It could be the prefix from the actual REST part that could have been wrong and generating 404 if in test is http:/192.168.0.1:8009/Magica/De/Spell/ and the production site is https://www.comune.amelia.tr.it/cms/restapi/ and one mistypes http://www.comune.amelia.tr.it/cmsrestapi/ is hard to spotin a hurry. And will generate 404

  • (nodebb)

    This reminds me of the time I worked at this one construction site and there was this safety guy who insisted that anybody who was off the ground had to use safety harnesses and anchor themselves to something. Including those on ladders; he made them latch on to the ladder itself.

  • King (unregistered) in reply to Mr. TA

    Brillant!

  • Edd (unregistered)

    Make sure to have a unit test when fixing a unit test.

  • CdrJameson (unregistered)

    Or you could add a configuration validation script, so when you propose a configuration URL it actually uses it and checks it doesn't get a 404 BEFORE it goes into the release configuration file.

    Having a system where one typo in a complicated string can bring the whole thing crashing down sounds pretty high-risk to me.

  • my name is missing (unregistered)

    We only test in stage environments and leave customers to find things broken in production. Doesn't everyone?

  • Foo AKA Fooo (unregistered) in reply to Steve_The_Cynic

    What makes you think he realized his mistake? If he did, he'd have closed the issue, not postponed it. It looks more like he noticed he might be wrong here, and to avoid further embarrassment, changed the topic, without admitting any mistake or waiving the right to nag the devs more about it in the future.

  • Andrew (unregistered)

    So Paramdeep, himself, is not a valid unit test? Strange, because his test worked.

  • (nodebb) in reply to MIKE

    Hmm. OK. To my eye that looks like a WTF of sorts, that the test server and production server have different URL path layouts. It inspires me to ask why they are different, and whether it wouldn't be better to handwave things so that they aren't different.

  • Rufus (unregistered) in reply to Steve_The_Cynic

    "Blonde moment"? Don't you have female colleagues to smack you on the head?

  • .. (unregistered)

    Come to think of it, I've not worked with a REST API that seemed to have some sort of endpoint that returns info about the API such as version, name, or the like. Would be helpful so that it could be tested that the right API is being used

  • Cidolfas (unregistered)

    This has happened to me before... a bug happens, so we're supposed to add a unit test to make sure it doesn't happen again... but the unit test would be extremely dumb. (E.g. "we used to have a race condition, so we changed all the code so a race condition is now impossible. Write a unit test making sure there isn't a race condition any more.") I could write the test to validate my fix, but it would be pointless to permanently add it to our test suite because... it's impossible now :o

  • markm (unregistered) in reply to Steve_The_Cynic

    I'm no expert on this, but it seems to me that if you used real-world URL's in your testing, it would have effects in the real-world.

  • (nodebb)

    OK, so the team lead has a blonde moment, the developer explains, and the team lead realises his mistake.

    Except he never really did. "Which came frist, the chicken or the egg. Prove your work."

    He only "got" it when it was pointed out the configuration wasn't even available during unit tests.

  • NoMoreOilAndGas (unregistered)

    I once had an argument that we could not start coding on a project until QA could make a test plan for the installer. In order to make the test plan for the installer, they needed to know every single file and location that the installer would drop. This was a green-field project with 0 lines of code existing, so obviously we don't know 100% how to code the entire thing, what to name assemblies, what dependencies are required, how to integrate it into the OS with an installer, etc.

    Their response "it sounds like you don't have a plan".

    Technically, they weren't wrong; It was development's fault that we did not code the entire thing in English via the user stories during planning.

    I didn't stay there much longer.

  • (nodebb) in reply to Steve_The_Cynic

    No, you're correct. You should have a host configuration setting, but also a base path setting in the event, for some reason, your production setup is different. So all the API calls work regardless and you only have to worry about 2 config settings being set properly...

    It definitely seems like a WTF that all the URLs are configuration though.

  • Dlareg (unregistered) in reply to Rufus

    Don’t you have blonde male cow-rokers?

  • Sole Purpose Of Visit (unregistered)

    I'm still not seeing the problem here. It's not really about URLs at all. It's about routing.

    You have three (clusters of) machine: [Testing], [Staging/QA], and [Production]. These you configure into your local DNS, and they translate into [192.168.x.x] and [192.168.y.y] and [a.b.c.d]. Or IPv6 equivalents.

    If there's any point whatsoever to the testing and staging and so on environments, it's that their structure mirrors the structure of the production environment. Therefore, the only thing you need to put into the config is the internal routing, ie the thing that follows the first slash after the DNS lookup. If you don't do that, then you're not reliably testing anything at all, are you?

    I'm sure I'm being a buffoon here.

    But the only thing that should be in config (of any sort) is the internal routing. The DNS destination should be configured on some other basis You want to tie it down, you have a Tester login (with an environment variable), a QA login (with an enviroment variable) and a Prod login (with environment variable). Or something like that.

    Unless I've missed something here (and I probably have), that just means you point at [Host] + [Routing]. You're not testing the first, you're testing the second. And if there's a problem with [Host], then that is not amenable to unit testing. It's amenable to firing the entire sysadmin department and starting over.

  • Staticsan (unregistered)

    This is why I dislike the current trend of putting environment configuration into the codebase. IMO, it doesn't belong in the codebase: configuration belongs to the environment. Default configuration belongs in the codebase, as you need defaults, of course. Then you override the ones that need overriding.

  • Dave (unregistered)

    Sounds a bit like being arrested for resisting arrest.

  • Naomi (unregistered)

    Reminds me of the clusterfuck at my old job. Half the automation was in TFS, half was in Jenkins, and the Jenkins jobs were a mass of "VisualBuildPro" (the less said about that "language" the better). It was all "maintained" by two older men in India, who really didn't appreciate a young woman with radical ideas like "maintainability" and "responding to support tickets" moving in on their turf. Hey, that might make for a good TDWTF post if I can find a good narrative hook.

  • Yazeran (unregistered) in reply to Sole Purpose Of Visit

    Unless I've missed something here (and I probably have), that just means you point at [Host] + [Routing]. You're not testing the first, you're testing the second. And if there's a problem with [Host], then that is not amenable to unit testing.

    One thing to remember is if the production system involves more than one host (where the different hosts handle different parts of the whole process) In that case you do need some sort of configuration to tell the system which host are used for what so users are pointed the right way or similar, and that configuration in most cases will be different between testing and production (different hostnames) One thins you could do in this case is having those 'global' host configurations in a separate file and the internal server configurations in an other, but then you have to maintain 2 configuration files...

  • (nodebb) in reply to markm

    I'm no expert on this, but it seems to me that if you used real-world URL's in your testing, it would have effects in the real-world.

    I was thinking more of the "full" URL being constructed when the process starts as:

      std::string api_url = api_host + api_path;

    or some function equivalent in the language used in the project. api_host is the configured API server host identifier, set according to the environment, and api_path is the path part, which is (or should as much as possible be) the same in all environments, and doesn't, as such, have to be configured. In the test environment, then, api_host is the name of the test server, and in the production environment, it is the name of the production server.

    The objective is to reduce as far as possible the number of variables between environments.

  • Dave (unregistered) in reply to Naomi

    a mass of "VisualBuildPro" [...] all "maintained" by two older men in India , who really didn't appreciate a young woman with radical ideas

    So VisualBuildBro, in other words.

  • Dave (unregistered) in reply to Steve_The_Cynic

    I was thinking more of the "full" URL being constructed when the process starts as: std::string api_url = api_host + api_path;

    Except that this being the DailyWTF it's not done with '+' but involves several lines of Perl, regexes that wrap twice around the screen, at least one pass through eval(), and something done via Excel.

  • MiserableOldGit (unregistered)

    This strikes me as dumb.

    Yeah, you don't put the configuration file through a unit test, but you certainly check it. The host constant should be fine, unless it changed, in which case careful attention should be paid. The "new" bit (basically, parameters), should have been tested already, so apart from a stray back slash I don't get the problem.

    Maybe the TL was a dickhead, but he was right this should never happened, but slightly wrong about why.

  • jochem (unregistered)

    Well, I get the point. The fact that a small mistake can cause serious issues at the customer is a problem. You need some form of quality assurance. Like a double manual check, fixed deployment template, configuration utility or fixed environment variables at the live server. You never want problems at the customer, or you can lose customers...

Leave a comment on “Configuration Errors”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article