5

Don’t mock your DTO objects or I will find you and I will kill you!

Comments
  • 1
    You mean plain-old-code classes?

    Why would you mock thoselol
  • 1
  • 1
    But why would you mock them?
    What crazy fuck would mock code?
  • 0
    Don't forget to write unit tests for your DTOs!
  • 2
    @alexbrooklyn

    >> Why would you mock those

    Visual Studio test code analysis tools flags DTO classes as not-tested (saying the get/set methods are not tested), artifically lowering the code-coverage %.

    We had a couple of 'hard-core' TDD-wanna-bees waste an incredible amount of time writing code like this:

    var foo = new Foo() {Id = 1};

    Assert(foo.Id == 1);

    100% code coverage isn't a goal, its a mental disorder.
  • 0
    @PaperTrail but that wasn't what it was about right?

    We were talking about mocking get/settersI thought

    Besides, in PHP I've written a reflection script once that tested all the getters and setters, code coverage went up pretty quick 😛

    Altho I doubt the hardcore tdds woulf approve of that
  • 1
    @alexbrooklyn

    >We were talking about mocking get/setters

    Sorry, I forgot to include they also mocked domain/DTO objects. They justified it because the owning project was a web service and they wanted the unit test project as 'pure' as possible. Whatever that was supposed to mean.

    They no longer work here and made it a mini-mission to delete any remnants of that nonsense.
  • 0
    @PaperTrail
    Ughh, that's rough. Worked somewhere ruled by an overpowered "OPs" grouped that dictated code standards. They were of course, also code coverage zealots, and the experience has caused me to regard SonarQube as a weapon. I honestly can't believe someone would write code like that while not under duress; I died a little each time I had to stamp my name on commits containing tests just like that to appease the build server gods >.<
Add Comment