YAGNI Test version



  • So, I don't know if I'm right about this or not, and I'm open to being told I'm wrong.

    This issue started up when I'm working with a guy that developed the code from a different part of the company. I'm testing the code, and his demo steps are very vague.

    In it, he made edits to commonMethodLibrary.dll.

    For some reason I won't defend, our code loops through categories of data, and for each category, builds a structure and inserts that into a hash. Certain categories aren't supported, and so we add code in there to print a log message and then skip building a structure.

    The customer complained about spurious log messages, and come to find out, the MAX_CATEGORIES was increased, and the code that referenced them wasn't updated to remove the errors.

    So, he makes an edit to fix this for a particular userLibraryX.dll.

    However, those new categories aren't used by userLibraryX.dll or any other userLibrary. So, he edited a fakeUserLibraryX.dll to test the new categories, complaining about people writing broken code that they haven't fully tested.

    However, this fake test scenario has led to all kinds of complications, because my system access is limited severely, due to him working for a different part of the company.

    So I finally cut him off and said "YAGNI". To which he completely opposed.

    I explained that, when we actually have need for the new data categories, we'll be able to test in an environment closer to our side, and won't have all this complexity in the way. So it's uneconomical to continue testing.

    Am I right? Is there a point where testing an unused possibility is uneconomical and YAGNI applies?

    EDIT: Well, now he took away my system access so he could continue trying to test it. 3 days down the hole for a scenario that we aren't even using. All to save a day's worth of work fixing it later if it were a problem.



  • @xaade said in YAGNI Test version:

    I'm open to being told I'm wrong.

    You're wrong. That's out of the way; now I'll read the rest of your post and find out what you're wrong about. :P


  • Winner of the 2016 Presidential Election

    @xaade said in YAGNI Test version:

    So, I don't know if I'm right about this or not, and I'm open to being told I'm wrong.

    WRONG

    This issue started up when I'm working

    WRONG

    with a guy that developed the code from a different part of the company.
    I'm testing the code,

    WRONG

    and his demo steps are very vague.

    this is probably correct

    In it, he made edits to commonMethodLibrary.dll.
    For some reason I won't defend, our code loops through categories of data, and for each category, builds a structure and inserts that into a hash. Certain categories aren't supported, and so we add code in there to print a log message and then skip building a structure.

    All of this is probably WRONG on a meta level!

    The customer complained about spurious log messages, and come to find out, the MAX_CATEGORIES was increased, and the code that referenced them wasn't updated to remove the errors.
    So, he makes an edit to fix this for a particular userLibraryX.dll.
    However, those new categories aren't used by userLibraryX.dll or any other userLibrary. So, he edited a fakeUserLibraryX.dll to test the new categories, complaining about people writing broken code that they haven't fully tested.
    However, this fake test scenario has led to all kinds of complications, because my system access is limited severely, do to him working for a different part of the company.
    So I finally cut him off and said "YAGNI".

    WRONG. You probably said more than one word!

    To which he completely opposed.

    correct

    I explained that, when we actually have need for the new data categories, we'll be able to test in an environment closer to our side, and won't have all this complexity in the way. So it's uneconomical to continue testing.
    Am I right?

    WRONG. You are on the internet!

    Is there a point where testing an unused possibility is uneconomical and YAGNI applies?

    Maybe YAGNIkuronue could apply!

    EDIT: Well, now he took away my system access so he could continue trying to test it.

    RIGHT

    Filed Under: You are welcome!

    addendum: @HardwareGeek I love how we both refused to actually read anything before deciding to just prove the post wrong :)



  • haha...

    but, seriously though.


  • I survived the hour long Uno hand

    It sounds like the problem isn't his testing the code, but the setup you're running, which you've been too vague about for me to really comment on. Why does it take more than three days to add a test?!



  • @Yamikuronue

    The setup is an actual customer system the project delivery is building, which is why my access is limited.

    That's the core of the problem, but when someone insists that I test a feature not being used on a system that I have limited access.... I feel like I'm being thrown under the bus when it takes days to pull off.



  • @Yamikuronue said in YAGNI Test version:

    Why does it take more than three days to add a test?!

    All tests are manual.

    I'm not adding a test. I'm performing it. One time.


  • I survived the hour long Uno hand



  • @Yamikuronue

    Oh, trust me, I've been shitlording over the real problem the whole time.

    There's only so many ways of saying "I will block this shit from every possible angle next time."

    But, the specific question, is whether there comes a point where it's not economical to test unused code, and so you don't.


  • I survived the hour long Uno hand

    @xaade said in YAGNI Test version:

    whether there comes a point where it's not economical to test unused code

    You're looking at it wrong. If it's not economical to test something, don't write it. That's where YAGNI comes in.



  • @Yamikuronue

    In usual cases, yes.

    Here's the deal. We were simply removing a log message saying a category wasn't supported, which isn't true.

    I suppose your fix would be to lower the max value so that those categories weren't even referenced by the code?


  • I survived the hour long Uno hand

    @xaade I literally can't picture what's going on here, unfortunately. The stuff you're talking about sounds like it should take ten minutes to test. You were getting errors, right? So something caused that. So do that again, and show that the error isn't there anymore?



  • @Yamikuronue said in YAGNI Test version:

    @xaade I literally can't picture what's going on here, unfortunately. The stuff you're talking about sounds like it should take ten minutes to test. You were getting errors, right? So something caused that. So do that again, and show that the error isn't there anymore?

    Yeah, sorry....

    convertCategory(ExternalDataCategory category)
    {
        switch(category)
        {
             case blah:
                  internalHashTable.add(new categoryStruct(InternalDataCategory.blah);
                  return true;
                  ...
             case dog:
                  Log.Write("Dog category not supported.");
                  return false;
             default:
                  Log.Write("I don't know what this is.");
        }
    }
    
    buildCategories()
    {
        foreach(var i = 0; i < CATEGORIES_MAX; i++)
        {
            convertCategory((ExternalDataCategory)i);
        }
    }


  • @Yamikuronue said in YAGNI Test version:

    @xaade I literally can't picture what's going on here, unfortunately. The stuff you're talking about sounds like it should take ten minutes to test. You were getting errors, right? So something caused that. So do that again, and show that the error isn't there anymore?

    Yeah, sorry....

    convertCategory(ExternalDataCategory category)
    {
        switch(category)
        {
             case blah:
                  internalHashTable.add(new categoryStruct(InternalDataCategory.blah);
                  return true;
                  ...
             case dog:
                  Log.Write("Dog category not supported.");
                  return false;
             default:
                  Log.Write("I don't know what this is.");
        }
    }
    
    buildCategories()
    {
        foreach(var i = 0; i < CATEGORIES_MAX; i++)
        {
            convertCategory((ExternalDataCategory)i);
        }
    }
    

    to

             case dog:
                  // this is supported
                  internalHashTable.add(new categoryStruct(InternalDataCategory.dog);
                  return true;
    

    And he wanted to test dog category, even though it's not being used.

    Whereas, I was fine with the error not being printed, which fixed the actual problem.

    He argued that, "that's how you introduce bugs, by not fully testing the code."

    To which I argued, "It's not economical to test this. It will be more economical to test it when the category is being used. This passes the defect resolution."


  • I survived the hour long Uno hand

    @xaade But if the error was being printed, you have some input that used Dog category, right? So just run that through and verify the output. Why does this take three days?

    I would say, if the customer doesn't give a rat's ass if they get Dog back, then just change it to "return true" and leave it at that. If the customer cares, you should test it. You should not wire up untested code and not test it.



  • @Yamikuronue said in YAGNI Test version:

    But if the error was being printed, you have some input that used Dog category, right?

    Oh, that's the fucking brilliant part. And that's where I spent half a day trying to figure out why he was telling me that it wasn't being used.

    It builds the category structure into the hash table, whether it's used or not.

    Why there's a fucking switch, when you're just going to call it with a foreach is beyond me.



  • @Yamikuronue said in YAGNI Test version:

    I would say, if the customer doesn't give a rat's ass if they get Dog back, then just change it to "return true" and leave it at that

    Actually, return false, just... don't print the error. Or just bump up the log level to INFO so it's not spamming them unless they're trying to figure out why Dog doesn't work. I suppose. Devs would still see that it's unsupported.



  • I'm failing to understand something here.

    Your system processes categories of data and generates log messages for unsupported categories. You get "spurious" messages because new, unsupported categories were added. Isn't generating log messages the expected behavior in that case? Are the messages not the right sort of message? What do you mean the categories are unused? Apparently something is putting those categories of data into the system, and you're getting "unsupported category" messages, no? Is that not an adequate test? If you need a formal test for documenting compliance or something, ISTM this should be easily testable at the unit level. (You do have unit tests, right?) Why is a system test necessary?

    Finally,and most importantly, what does the spec say about this situation? If it says, "All unsupported categories must result in an 'unsupported category" message," and these new categories exist and are unsupported, then you have to test that behavior. If it enumerates the supported and unsupported categories, and the new ones aren't listed in either, then maybe you can get away without testing them; their existence is, itself, a spec violation. If A violates the spec by providing invalid data, B's response to the data is UB. Maybe, depending on what the spec actually says.

    Since we don't know what the spec says, any answer we give you is, at best, a guess.

    In general, though, YAGNI may be a valid response to testing behavior that isn't specified. Testing that your C compiler produces a particular result for i = ++i + i++; is pointless, since there is no requirement for it to do so. OTOH, if the spec says the behavior should be X, you test for X, whether it matters now or not. Or you get the spec changed.

    Or at least you document that testing $feature is being deferred until some future project needs that feature. Yes, if a $thing is reusable, implementing a $feature now may make sense even if it isn't needed yet, especially if it changes the way other features would be implemented. However, deferring the testing may also make sense. Why delay project 1 to test a feature it won't even use? Let project 2 test their own feature.

    Wow, that was longer and more rambling than I intended. Oh, well; deal.

    Edit: I a couple of words.



  • @HardwareGeek said in YAGNI Test version:

    Isn't generating log messages the expected behavior in that case?

    My opinion, it's broken, because it's logging messages for unsupported categories.

    It accesses this code because it blindly loops through arbitrary count up to MAX.

    max = 30;
    foreach(i through max)
    {
        switch(i)
            case 29:
                "durh duh dumb unsupported type... why am I doing this?"
    }
    

    So, even if category 29 is NEVER EVER used, the code that builds the lookup will generate log messages.

    It's difficult to understand because it's stupid and you're expecting something smart.

    When it builds the lookup, then the external code references the lookup, which has all possible items.

    They should be logging when the external code requests a data category that isn't supported, but it's logging when it builds the lookup.



  • @xaade I'm afraid in still confuzzelled. I thought I understood from the clarification you posted while I was typingtapping my previous wall-o-text™, but now I'm confused again.

    Is "dog" supported, or not?
    Is it partially supported — by the front end but not the back end, or vice versa?
    Is it supported, but the category has no data (and you don't expect there to be any soon)?
    Is there "dog" data, but the consumer isn't expected to request that category?
    Is the "external code" the producer, consumer, or both?
    Is the problem that the consumer is seeing a log message about a category that is unsupported and/or unused even when it has not expressed any interest in that category and doesn't care whether it's supported?
    If the answer to the previous question is yes, was that the scope of the bug fix? Or was the requirement to add the support?

    If the bug was simply that the consumer was receiving messages about irrelevant categories, then adding support for those categories is beyond the scope of the requirement. However, if the system is now claiming to support them (by no longer saying it doesn't), then it's lying unless that support is tested. If the decision was made that the correct way to eliminate the "unsupported category" messages was to support the categories (and in an ideal world, the spec was updated to reflect that, ha,ha), the support definitely needs to be tested, although deferring the testing until it's needed might be a reasonable thing to do.



  • @xaade That is the most boring thing I have ever read.



  • @lucas1 said in YAGNI Test version:

    @xaade That is the most boring thing I have ever read.

    Wait 'til you read my Walls-o-text™.



  • @HardwareGeek That is the great thing about replying. I know to ignore it.



  • @xaade said in YAGNI Test version:

    Why there's a fucking switch, when you're just going to call it with a foreach is beyond me.

    It this the object-oriented version of the FOR-CASE paradigm?



  • @ben_lubar said in YAGNI Test version:

    @xaade said in YAGNI Test version:

    Why there's a fucking switch, when you're just going to call it with a foreach is beyond me.

    It this the object-oriented version of the FOR-CASE paradigm?

    It is for this one particular spot.

    Like I said, the convert is used again when the code actually wants to access a single one of them. But in one spot in the code, it's iterating through every one of them, including the unsupported types, which caused the spurious log messages. Ironically it's aware some return false, and "continues" if that's the case.

    If it were me, I would have just thrown in an argument that told it not to log a message.



  • @ben_lubar said in YAGNI Test version:

    @xaade said in YAGNI Test version:

    Why there's a fucking switch, when you're just going to call it with a foreach is beyond me.

    It this the object-oriented version of the FOR-CASE paradigm?

    Wait, why are people in the comments continuing to suggest a loop at all?

    In my case the constants that are being converted already map to integers, so at least there a loop makes sense.



  • @xaade I suppose you should add a verbose level setting and mute the "category not supported error" completely under certain level. Chances exists there are other people that uses your library will need that error messages for debugging.


  • I survived the hour long Uno hand

    @xaade said in YAGNI Test version:

    why are people in the comments continuing to suggest

    Front page commenters. Nuff said.


  • Discourse touched me in a no-no place

    @HardwareGeek said in YAGNI Test version:

    @xaade I'm afraid in still confuzzelled. I thought I understood from the clarification you posted while I was typingtapping my previous wall-o-text™, but now I'm confused again.

    My understanding:

    1. The code is aware of lots of categories, including those that are currently unsupported.

    2. As part of initialisation, the code goes through each category it's aware of, sets up data structures for those it supports, logs an "unsupported" message for those it doesn't.

    3. Data subsequently comes in, but none of that data contains unsupported categories.

    At issue, I think, are the uninformative unsupported messages during initialisation in (2), when instead they should be being produced if unsupported categories occur during (3), which if I'm reading the OP correctly, will never happen anyway.

    And I think the question was, should testing be performed to account for unsupported categories appearing during (3) especially if "it will never happen" and perhaps more pertinently "there is little to no access to the only system where it can be tested on."



  • @PJH said in YAGNI Test version:

    As part of initialisation, the code goes through each category it's aware of, sets up data structures for those it supports, logs an "unsupported" message for those it doesn't.

    Only for a specific command.

    @PJH said in YAGNI Test version:

    Data subsequently comes in, but none of that data contains unsupported categories.

    Data can come in for an unsupported category. If it does, a message is logged and the data is skipped. This is normal and reasonable behavior. It's the other place in code where they loop through where the intent isn't to actually access all of those field conversations for external use.

    @PJH said in YAGNI Test version:

    At issue, I think, are the uninformative unsupported messages during initialisation in (2), when instead they should be being produced if unsupported categories occur during (3), which if I'm reading the OP correctly, will never happen anyway.

    YES!!!

    @PJH said in YAGNI Test version:

    And I think the question was, should testing be performed to account for unsupported categories appearing during (3) especially if "it will never happen" and perhaps more pertinently "there is little to no access to the only system where it can be tested on."

    Yes!!!

    Finally...


Log in to reply