The Daily WTF: Curious Perversions in Information Technology

Bobby Tables · 2014-02-14 Reply Admin

chubertdev:
D-Coder:
chubertdev:
a; er:
....the real skill would be finding potential defects that you didn't think of....if you know what I mean

as we know, there are known knowns; there are things we know that we know. there are known unknowns; that is to say, there are things that we now know we don't know. but there are also unknown unknowns – there are things we do not know we don't know.
Aren't there also unknown knowns? Things that we don't realize that we know, but we do?

Hmmm...

Yes, but I wasn't aware that I knew that.

Feature this, please.

2014-02-14 Reply Admin

Slipping into girlfriend speak now: "If you don't know why then there is no point in me explaining it to you"

If I really don't know why, and you aren't going to explain it to me, what do I have to do to find out?

2014-02-14 Reply Admin

Bananas:
so he went to look and see what he needed to change to update the tests.
Excuse me? Your code changes break the unit tests and your first response is to start making changes to the tests? You need to fix your code, NOT change the unit tests.
Matt, the door is that way, and don't let it hit you on the way out.

Do the unit tests check the correct behaviour? If they fail because the expect the behaviour, then obviously the unit tests need changing. There's no guarantee that unit tests are bug free. Especially if requirements have changed, and you changed all the code but not the unit tests, unit tests will fail - and you have to change them.

2014-02-14 Reply Admin

Jim Blog:
That's a bugbear of mine - unit tests that swallow a perfectly usable exception and replace it with a completely generic "oh, something broke". The original exception should at a minimum be logged somewhere first. Unit tests shouldn't be written to purposefully frustrate the person who has to diagnose the failures...

That's what you have a debugger for. First pass, set a breakpoint on the failing test, check what bad result you got. Second pass, step through the code giving the wrong result to see why you got the bad result. All I need to know is the name of the test. Writing the test should be as little work as possible, because being little work per test, more tests will get written.

2014-02-14 Reply Admin

gnasher729:
Jim Blog:
That's a bugbear of mine - unit tests that swallow a perfectly usable exception and replace it with a completely generic "oh, something broke". The original exception should at a minimum be logged somewhere first. Unit tests shouldn't be written to purposefully frustrate the person who has to diagnose the failures...

That's what you have a debugger for. First pass, set a breakpoint on the failing test, check what bad result you got. Second pass, step through the code giving the wrong result to see why you got the bad result. All I need to know is the name of the test. Writing the test should be as little work as possible, because being little work per test, more tests will get written.

Just that swallowing an exception and replacing it with another one is usually more work (than doing nothing at all), see yesterday's counter-example.

2014-02-14 Reply Admin

TGV:
anonymous:
Watchman:
Who tests the test code?
It's testers all the way down.
No, at the end there are four elephants on the back of a turtle. Everyone knows that. Here, take a blue pill.

Turtles mate, turtles.

Coyne · 2014-02-14 Reply Admin

They must have been paying someone piecework, by the unit test created.

Kind of like offering to pay programmers for every source line written. Like in this "two-for-one" example I just ran across:

      MOVE SOURCE-TRAN-TIME        TO NS-TRAN-TIME      
      MOVE ZERO                    TO NS-QUEUE-NUM  
      MOVE USE-CODE                TO NS-USE-CODE
      MOVE CLIENT-CODE             TO NS-CLIENT-CODE   
      MOVE LOWEST-POSSIBLE-TIME    TO NS-TRAN-TIME

(And the programmer wasn't even being paid per source line. Imagine if he had been...)

2014-02-14 Reply Admin

I prefer something like:

@Test public void testNoExceptionsAreThrown_TC1234() { try { doIt(); } catch (Exception e) { Assert.fail(); } }

chubertdev · 2014-02-14 Reply Admin

Marley:
TGV:
anonymous:
Watchman:
Who tests the test code?
It's testers all the way down.
No, at the end there are four elephants on the back of a turtle. Everyone knows that. Here, take a blue pill.
Turtles mate, turtles.

And they're green, too.

2014-02-14 Reply Admin

Watchman:
Who tests the test code?

The Test Nazis!

Also, this isn't spam. Even though Akismet may think otherwise.

2014-02-14 Reply Admin

TGV:
The number is cumbersome, but the test case should be copied in the comment.
Anyway, there's not always a need for an assert in a test case. If Hold or Retrieve throw an exception, the test fails.

I believe in some testing frameworks you need to explicitly say "expect no exception", though.

2014-02-14 Reply Admin

gnasher729:
Jim Blog:
That's a bugbear of mine - unit tests that swallow a perfectly usable exception and replace it with a completely generic "oh, something broke". The original exception should at a minimum be logged somewhere first. Unit tests shouldn't be written to purposefully frustrate the person who has to diagnose the failures...

That's what you have a debugger for. First pass, set a breakpoint on the failing test, check what bad result you got. Second pass, step through the code giving the wrong result to see why you got the bad result. All I need to know is the name of the test. Writing the test should be as little work as possible, because being little work per test, more tests will get written.

You create more work, for no benefit, and when I complain your response is "use more tools!"?

You're assuming that the tests are always run on my machine in EclipelliXcode with debug mode enabled.

Or I could just see the exception thrown in the email I get from the Build system, and say "oh, NullPointerException, must've remove a property that's still being used. Let me fire up vim real quick and fix that, Sorry guys."

2014-02-14 Reply Admin

Hannes:
Watchman:
Who tests the test code?
The Test Nazis!

You're an impostor.

http://en.wikipedia.org/wiki/Hanzo_the_Razor

I'm back.

2014-02-15 Reply Admin

Hanzo:
Hannes:
Watchman:
Who tests the test code?
The Test Nazis!
You're an impostor.
http://en.wikipedia.org/wiki/Hanzo_the_Razor

I'm back.

No. I'm the real Hannes.

2020-01-13 Reply Admin

Not a WTF. They're clearly just testing cargo units for the Galactic Terran Alliance.

TC119a()

Leave a comment on “TC119a()”