Unit testing

Symantec / Eng
haik

Go to company page Symantec Eng

haik
Nov 5, 2018 11 Comments

In our org we are pretty ging ho about unit testing. Every bit of code needs to have near 100% unit tests. Which means right from design we need to make the code testable. Example never call APIs directly, call through interface wrappers etc. Make class members protected not private for testing. And a ton more. Factory implementation is given high importance as it makes it easy to implement tests.

I have friends in other companies who work on similar tech as we do (windows kernel). They completely disagree with this strategy say unit tests are bull crap.

Honestly to me unit tests make sense, u develop each class and test it, eventually the entire product is tested, where us the functional test approach of top down testing leaves gaps.

Yes it is much easier to implement unit test for new products as I said, we need to consider it while designing, and legacy code won't lend much to it, but let's leave coDe age aside, and talk just about benefits and philosophy at this time.

Wanted to get your views about this.

comments

Want to comment? LOG IN or SIGN UP
TOP 11 Comments
  • McAfee
    JohnMcPee

    Go to company page McAfee

    JohnMcPee
    “I have friends in other companies who work on similar tech as we do (windows kernel). They completely disagree with this strategy say unit tests are bull crap.”

    You need to get new friends.
    Nov 5, 2018 0
  • Devs make up excuses not to write unit tests. Or they have an incorrect definition of unit tests and then write a few pseudo unit tests.
    These devs become dev managers, and they don't see the value of true unit tests...and so, we have a generation full of devs, which doesnt believe in the effectiveness of true unit testing.
    At the same time, they all pretend and deceive themselves that they know how to test their stuff.
    Nov 5, 2018 0
  • Microsoft / Eng
    deadpan

    Go to company page Microsoft Eng

    deadpan
    Working in code that has a good test suite is more fun, because you find regressions quickly. In my experience this has been especially good for code near the bottom of the stack.

    But in some areas the bugs mostly strike during integration. The hard part isn't in getting units to work, it's in getting a bunch of units to play nice together. Passing unit test suites only help a little bit, because the contracts change rapidly in response to various factors for various units. Passing unit tests don't imply working systems. Keeping suites current ends up costing more and benefitting less. This has often been the case when working at the top of a tech stack.

    I'm not sure if the top/bottom thing is common or just the things happened to be in the products I've worked on. So just read that as an observation, not a prescription.

    Mostly, I'm a fan. I'd rather work in code that has good test suites. Mostly.
    Nov 6, 2018 3
    • Microsoft / Eng
      deadpan

      Go to company page Microsoft Eng

      deadpan
      I agree that loosely coupled, easily testable code is always better than having tightly coupled, barely-testable code. Being able to mock things out is always a win.
      Nov 6, 2018
    • Symantec / Eng
      haik

      Go to company page Symantec Eng

      haik
      OP
      I would always go for mocks than fakes. I always avdice folks to justify tight coupling in code reviews, and they should explain why they think they want to fake(tight coupled) the object rather than mock(lose coupling) it.
      Nov 6, 2018
  • Expedia
    %Obviously

    Go to company page Expedia

    %Obviously
    It really depends on your architecture and specifics. I’ve worked in a codebase where individual unit tests were damn near useless due to the nature of the application (akka is guilty of this often) , integration and feature tests were more useful, especially as we were actively refactoring everything.
    Nov 5, 2018 2
    • Symantec / Eng
      haik

      Go to company page Symantec Eng

      haik
      OP
      Please give an example of such an application
      Nov 5, 2018
    • Expedia
      %Obviously

      Go to company page Expedia

      %Obviously
      Legacy applications where theres too many dependencies, for one thing. Actor model, is another.
      There is no hard set rule -write the tests that you think will give you maximum assurance that the product works as expected.

      Having said that, I’ve seen some issues with DI and frameworks that use non deterministic resolution strategies for dependencies where automated testing testing simply cannot catch the problem because it’s random. Usually comes bundled with bad engineering habits.
      Nov 5, 2018
  • New
    aLuu55

    Go to company page New

    aLuu55
    Unit tests are extremely important, they’ve saved me huge amounts of time catching bugs dead in their tracks.

    A well written test suite has a lot of unit tests, a smaller number of integration tests, and a few end-to-end tests. It’s basically a pyramid.

    I am a firm believer in testing because it really helps clarify your thinking about what you expect your code to do, and helps to catch problems really early on before they turn into time consuming bugs.

    I used to never write tests, and as a result I wrote a lot of buggy code that was a pain to debug. Unit tests might seem like a waste of time, but in the end, a good test suite will be tremendously valuable.
    Nov 5, 2018 0