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

  • 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

    >> 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

    >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
    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