Unit Fighting


  • Dupa

    @masonwheeler said in WPF best practices:

    mocking: n. What should be done, quite thoroughly and derisively, to people who advocate turning simple, straightforward source code into a mass of complexity and layers and "decoupled" pasta, in order to make it easier to run automated tests against.

    Yeah, sure. I’m doing an emergency release tomorrow because my predecessor didn’t have time for unit tests.

    Somehow, I never receive bug reports for the code that is covered with good unit tests. Go figure.


  • Impossible Mission - B

    @kt_ said in WPF best practices:

    I’m doing an emergency release tomorrow because my predecessor didn’t have time for unit tests.

    Somehow, I highly doubt that's the actual reason why you're doing an emergency release.


  • Dupa

    @masonwheeler said in WPF best practices:

    @kt_ said in WPF best practices:

    I’m doing an emergency release tomorrow because my predecessor didn’t have time for unit tests.

    Somehow, I highly doubt that's the actual reason why you're doing an emergency release.

    It’s a simple issue that good unit tests would catch.

    Think of unit tests as a fail safe: they force you to again think about your code and examine it closely. After writing it.

    Just like code review.

    Another thing: I spent a few hours validating that what he wrote wasn’t on purpose. Good unit tests serve as a spec. I’d know it was a bug right away.


  • Impossible Mission - B

    @kt_ said in WPF best practices:

    It’s a simple issue that good unit tests would catch.

    undefined

    Hindsight's 20/20. It's easy to look at almost any bug after the fact, knowing exactly what the bug is, and imagine up a simple test that "would have caught it." Actually coming up with that test beforehand, though, is a very different matter. This is actually one of the strongest arguments against test-first development:

    1. Your tests can only catch things they were designed to test for
    2. You only write tests for things you're already aware might be a problem
    3. If you're already aware it might be a problem, that means you're paying enough attention to that specific aspect that you're going to end up getting that part right, so what good does the test do?

    Good unit tests serve as a spec

    And so do bad ones, unfortunately. If the test has a bug, that bug becomes part of the spec rather than getting fixed.



  • @masonwheeler said in WPF best practices:

    If you're already aware it might be a problem, that means you're paying enough attention to that specific aspect that you're going to end up getting that part right, so what good does the test do?

    What good does it do? It keeps you from being Jeff Atwood. More precisely, someone is less likely to break it in the future. Regressions are pure waste. Unit tests are a very effective solution to regression.


  • Dupa

    @masonwheeler said in WPF best practices:

    @kt_ said in WPF best practices:

    It’s a simple issue that good unit tests would catch.

    undefined

    Hindsight's 20/20. It's easy to look at almost any bug after the fact, knowing exactly what the bug is, and imagine up a simple test that "would have caught it."

    It’s easy to disregard the main points of my posts. Unit tests give you: a chance to reflect, a spec and an easy way to refactor code, even if you’re not the person who wrot it.

    This is actually one of the strongest arguments against test-first development:

    Never said anything about TDD, so I’ll happily disregard the rest of your post.

    Oh wait, I can’t, because it’s stupid.

    1. Your tests can only catch things they were designed to test for
    2. You only write tests for things you're already aware might be a problem
    3. If you're already aware it might be a problem, that means you're paying enough attention to that specific aspect that you're going to end up getting that part right, so what good does the test do?

    That’s an awful lot of non sequiteurs. You write tests for what you come up with. You do the coming up while writing the code. Ergo, with TDD you have to think about every line of code. If you don’t do TDD but still write tests, you still have to think about how your code will react, because you want to test it.

    Either way, you get one more chance to take a thorough look at your code and with a very inquiring eye: you’re trying to break it, after all. And how! Line by line, and not click after click.

    And of course you purposefully don’t respond to the argument about refactoring and the fact that you can treat them as spec.

    I know your next argument: but that’s what good unit tests are like. Bad unit tests don’t give that, bad unit tests are shit! Well, bravo, Sherlock, you just realized that shit code is shit. Go have a drink, you deserve it.


  • Dupa

    @kt_ said in WPF best practices:

    I know your next argument: but that’s what good unit tests are like. Bad unit tests don’t give that, bad unit tests are shit! Well, bravo, Sherlock, you just realized that shit code is shit. Go have a drink, you deserve it.

    @masonwheeler Huh, what do you know. That’s the exact point you made in an edit. How’s that for anticipation?

    Bravo, @kt_. Bravo, I say!



  • @kt_ Calm down man, he's active on stack overflow. He can't help it. He probably has javascript on him.


  • Impossible Mission - B

    @kt_ said in WPF best practices:

    @masonwheeler Huh, what do you know. That’s the exact point you made in an edit. How’s that for anticipation?

    That's not the point I made in the edit; the point I made is that bad tests are actively harmful. This isn't simply an opinion; it's something that's been studied and consistently happens.


  • Dupa

    @masonwheeler said in WPF best practices:

    @kt_ said in WPF best practices:

    @masonwheeler Huh, what do you know. That’s the exact point you made in an edit. How’s that for anticipation?

    That's not the point I made in the edit; the point I made is that bad tests are actively harmful. This isn't simply an opinion; it's something that's been studied and consistently happens.

    That not the point I made; the point I made is that untested bad code is actively harmful. This isn’t simply an option; it’s something that’s been studied and consistently happens. ;;

    and one more: ; for good measure;

    ;;



    1. Bad code is bad.
    2. It's still bad if it's in a test.
    3. If code is in a test, it should be really explicit.
    4. Code should be reviewed before it is added to the repository.
    5. Code should be tested before it is added to the repository.
    6. Since tests are code, they should be reviewed too.
    7. If bad tests are in your repository, it's your fault.

  • Dupa

    @masonwheeler hey, but you’re the guy who still believed that camel has two humps. In 2017.

    Explanation:

    Nevertheless, I will read your link. What the hell! Not now, but I will. I promise. None of the points you make are able to convince me, so maybe this article will be able to sway my opinion, or at least pique my interest.

    I mean this in a good way. No sarcasm intended.


  • Dupa

    @magus said in WPF best practices:

    1. Bad code is bad.
    2. It's still bad if it's in a test.
    3. If code is in a test, it should be really explicit.
    4. Code should be reviewed before it is added to the repository.
    5. Code should be tested before it is added to the repository.
    6. Since tests are code, they should be reviewed too.
    7. If bad tests are in your repository, it's your fault.

    Yeah, I think a lot of it comes down to how responsible you feel for the codebase. Because upkeep costs. Tests cost, code review costs, refactoring costs.

    I work at a place where churning out features is really important and I work with a few people who are really good at this, who can make do without all that upkeep stuff and they still create relatively bug free features fast. But I’m not sure. I think the code is too important, and the vision of someone else having to maintain it too, to just let it rot. I’m with Bob Martin on that.

    Upkeep costs and doing it wrong might lead to horrible consequences. But not doing it might so even more.

    Of course not saying that you, @masonwheeler, specifically, fail to do any of these — apart from tests, which you happily admitted to yourself! It’s just a general observation.

    Either way, @mods, this should probably be Jeffed?



  • @masonwheeler said in WPF best practices:

    Actually coming up with that test beforehand, though, is a very different matter.

    Actually, it's fairly easy. All you have to do is cover all possible code paths (100% code and branch coverage). Wherever you validate input, have at least one test for each type of valid input and at least one test for each rejection reason. Also, in addition to unit test, have at least one test that takes everything together and tests the whole functionality from start to finish. These rules require next to no thinking and cover 95% of things that can go wrong. Also, to prevent regressions, for every bugfix have at least one test that verifies if it's fixed.

    @masonwheeler said in WPF best practices:

    This is actually one of the strongest arguments against test-first development

    No one in their right mind advocates tests-first approach. The only person I know who takes it seriously also insists on all functions being 4 lines or shorter.


  • Impossible Mission - B

    @gąska said in WPF best practices:

    Actually, it's fairly easy. All you have to do is cover all possible code paths (100% code and branch coverage).

    There is nothing at all easy about that. It literally requires orders of magnitude more code in your tests than in your production codebase. (I'm aware of only one project that's actually done it: SQLite, whose tests outweigh production code by a factor of something like 20,000.)



  • @kt_ said in WPF best practices:

    Either way, @mods, this should probably be Jeffed?

    With a View Jeff or a Model View Jeff or an overly Controlling Jeff?



  • @masonwheeler said in WPF best practices:

    @gąska said in WPF best practices:

    Actually, it's fairly easy. All you have to do is cover all possible code paths (100% code and branch coverage).

    There is nothing at all easy about that. It literally requires orders of magnitude more code in your tests than in your production codebase.

    OK, maybe 100% is too much. But 95% is very realistic and requires only 2x as much test code as production code - most of which will be copy-pastes with slight variations. If you end up with much more, it's a sign a refactoring is due.



  • @boomzilla oh for fuck's sake you just had to jeff right when I was replying!



  • @boomzilla said in Unit Fighting:

    @kt_ said in WPF best practices:

    Either way, @mods, this should probably be Jeffed?

    With a View Jeff or a Model View Jeff or an overly Controlling Jeff?

    Someone should make a backronym for MVC/MVVM/whatever that is JEFF.


  • Dupa

    @boomzilla said in Unit Fighting:

    @kt_ said in WPF best practices:

    Either way, @mods, this should probably be Jeffed?

    With a View Jeff or a Model View Jeff or an overly Controlling Jeff?

    Why, with a Unit Jeff Controller Monitor Manager Widget Stuffer, of course!


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.