• (author)

    This code also has some problems with the null key and null values. Those are unusual but are permitted by the language. Probably the programmer "just happens to know" that the application at hand doesn't actually use a null key or null map values BUT THAT DOESN'T MATTER. That is forbidden global knowledge and should be ignored.

    I've spent way too long bending my brain on this method and I'm not 100% certain I got the multiple negation right. I tried to rewrite it to see if breaking it down will clarify things, and I think I got it, but I'd need to make up some test data to be sure.

  • (nodebb)

    "The unit test method should worry about that kind of plumbing, not a supporting method which exists to perform a check." - Do not forget DRY.... if there is a reason to "sleep" then there should be only one place in the entire codebase that does that sleep [this is also SRP from SOLID]. Highly doubtful that the "unit test" is the right place to do it either....

  • (nodebb)

    I can imagine a manager taking pride in how long their unit tests take to run.

  • Robin (unregistered)

    Not even any comment on the empty catch! I find it hard to see how thread.sleep could throw (but I'm not really up on Java or C# or whatever this is), so it's likely completely unnecessary anyway - but if it somehow does we'd probably want to know why rather than just have it silently ignore the error!

  • Emma (unregistered)

    So. it could also have one or more of the following reasons: 1.) The language standard does not correspond to what was found in the literature (in my case the German one which is always just a few years behind) when the chief developer started. Does anyone else know 'goto' combined with global variables instead of even a single function or local variable? Actively used in 2022? 2) "The compiler has a bug there, you have to do it by hand. There is a piece of code you can copy..." (Apart from copying... it was about Sort... and in the time I was there the compiler vendor was changed, and also there it went a few versions further, but if there was a bug there before...) 3) A boss who wants to have everything logged to the second ("3 minutes nothing done, because waited for {...}" <- no! this is not a joke!) and always looks into the pull requests - and complains why it took so long for such a simple correction (a single condition changed). If you took a long time, you will eventually build in something nonsensical, which does not break anything (see point 1) and whose result is also used. For example a possibility to create files with a maximum size when zipping, instead of using the possibility built into the zip program... or did point 2 also play a role there? Never mind....

    And yes, such software can gain market share even today.... In the meantime I have cancelled there... despite an offer with much more money (30 %), much more vacation (50 %!) and also on top of a lower working time (only 10 % less). And that was at the beginning of the year, so before inflation went up so much.... Maybe I'm stupid for switching jobs.... but I'm definitely happier.

  • (author) in reply to Robin

    Sleep throws an exception if the thread is interrupted while sleeping, so it's not uncommon to just ignore that.

  • Sauron (unregistered)

    This actually an excellent unit test... to test the sanity of the devs.

  • (nodebb) in reply to Emma
    1. "The compiler has a bug there,

    My experience of compiler bugs (outside the "optimise for speed" option in VC++ 5 and 6 which were buggier than all hell) is that they are rare but they do exist. Part of my current company's codebase features one module written in C where the coding rules mandate, just for that module, that every goto label is followed immediately by a semicolon. (labelname:;). I eventually tracked down an approximate explanation, in that some antique compiler we probably haven't used even once in the last fifteen years (but might in theory use in the future???) would do something stupid if the semicolon wasn't there.

  • Duke of New York (unregistered)

    TheCPUWizard/Robin: This is test code. It can be sloppy and repetitive, as long as neither interferes with detecting incorrect program behavior.

    Read Robert Martin and other gurus if you want, but don't raise them to dogma. You'll create more problems than you solve.

  • MaxiTB (unregistered)

    Wow, Java is so verbose and hard to read because it doesn't have basic features like indexers, properties or var declarations... it reads like something from the last millennium :O

  • (nodebb)

    I'm thinking the sleep might be the legacy of someone complaining that it ran so fast it couldn't have been actually testing anything.

  • ichbinkeinroboter (unregistered)

    Test code is code. It can have bugs, it needs to be maintainable etc. etc. All the same things. Since even best case you end up with AT LEAST as much test code as code (usually more) you need it to be just as good and easy to work with as the rest of the code.

  • (nodebb)

    It takes 30 seconds to run this unit test suite. Wow, that one takes 48 seconds and this other one takes 9 seconds even though the class under test only has four methods. Amazing test coverage.

  • (nodebb) in reply to Remy Porter

    Sleep throws an exception if the thread is interrupted while sleeping, so it's not uncommon to just ignore that.

    I would argue that, in this case, while it might not be uncommon, it is wrong.

    That is unless, there's a unit test "fast mode" that is implemented by interrupting the thread from another thread.

  • Duke of New York (unregistered)

    Test code isn't "worked with" in anything like the way that product code is. Cases don't call other cases. The data is purposely concrete, not abstract. Factoring test suites the way that one would factor product code is likely to obscure them.

  • (nodebb) in reply to Duke of New York

    "This is test code. It can be sloppy and repetitive, as long as neither interferes with detecting incorrect program behavior." - EXCEPT that test code, experimental code - all of it - are knowledge repositories that may be accessed for years (decades even - I am working on code written in 1992, still using things like OCX along with the latest MAUI and Blazor; and everything in between..... Since there are no developers who have been on the project for 30 years, looking at the revisions of tests and other suplementary artifacts is about 70% of the workload to gain understanding.

  • dereferenced null pointer (unregistered)

    The appliaction I currently fight against doesn't have a single bug or error in any unit test...

    you can guess why.

Leave a comment on “It's Not That Different”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article