-1

It's impossible to have 100% code coverage for unit tests in real life. But it seems like my colleagues like to write unit test cases and happy flow functional test only. In the end, tickets are rejected by QA and they have to spend more time in refactoring again.

Verena Law
  • 1

2 Answers2

1

There is a risk in being unjust to your colleagues when answering your question, because you do not give a specific code example to discuss about. Therefore, there is certainly a chance that your colleagues are truly overdoing it with unit-testing as is your view on it, but it is also possible that they are doing it properly.

However, it is also my observation that there are certain people who, to speak generally, try to manage the difficulties of the craft of software generation (including testing as well as lots of other activities) by setting up simple rules. Since the habitually prescribed rules give some good guidance for a certain fraction of the cases, it requires quite some self-confidence, experience, will and capability to argue against them in cases where the rules are too simplistic.

Talking about code coverage, the more the better, right? At least many people at first think like this. At this stage they may not even be aware that there are different coverage criteria (statement coverage, branch coverage, ...). They may not even have a clear understanding what distinguishes unit-testing from interaction-testing (integration-testing) and subsystem-testing (component-testing or functional-testing). Only if you gain more experience and if you are interested in extending your knowledge about testing methodology you will learn more and more and possibly understand at some point in time where what kind of approach will be most beneficial.

But, even if you reach that point, you still have to be willing to argue with those who have set up the organizational or project rules in the first place: These are often enough parties that have not much of practical experience with software development themselves, like, customers or quality assurance people. To convince these people that the rules they have chosen will not fit in this or the other case requires to teach them a lot - which takes a certain effort and sometimes may be completely useless if they are not interested in extending their knowledge.

But, even if at some point they agree to your view and accept that in your case an exception is OK, they are hesitant to relax or refine the rules: Often these parties consider the group of developers as a bunch of morons that only by setting firm rules can be trusted to write software that does not come with bugs due to violation of fundamental rules. Like, people writing only few unit-tests or even no unit-tests at all unless you set some high test coverage goal for everyone. And, unfortunately, their experience proves them right on that.

Maybe those lines above seem to be a bit pessimistic. What is the solution? A solution is an organisation that takes quality serious and understands that the essence of software quality (in your case test quality) is fundamentally different from fulfilling simple metric criteria or following simple rules. For tests to have high quality, an organisation has to be willing to invest into testing in the right way, by ensuring all parties understand the respective goals of the different kinds of tests and having developers and testers argue about test cases, the way test code is written etc. "Rule driven software development" needs to be transformed into "software development driven by understanding", but such a transformation is hard.

Dirk Herrmann
  • 5,550
  • 1
  • 21
  • 47
0

It's impossible to say what motivates the specific developers you're working with, but unit tests can be:

  • Faster
  • Easier to set up / tear down (because they tend to rely less on external resources)
  • Easier to write since you have access to internals
  • Less flaky (because they tend to rely less on external resources)

Having solid regression tests is important, but any test that can be written as a unit test probably should be.

Aaron Bentley
  • 1,332
  • 8
  • 14