-3

Do I need unit testing for everything? I know that Unit testing is not necessary for really small tasks, but what about for bigger stuff? How do I know I need a unit test?

3
  • In the context of your question, how small is "really small" ? How big is "bigger stuff" ? Jul 5 '19 at 1:08
  • If you asking a question "Do I need unit testing for <something>" - you are most obviously don't need them for <something> task.
    – Fabio
    Jul 5 '19 at 1:21
  • @Fabio and then there is the idea that any code that doesn't have a unit test is broken by definition, which several places I've worked for adhered to religiously. Reality is somewhere in between.
    – jwenting
    Jul 5 '19 at 4:15
1

Exercise the public interface of all classes and all utility functions. Doesn’t matter how “small” the feature is, you can still get regressions.

0

I think you're going to find many different answers on this topic, since there is no one, clear cut way to approach testing. Unit tests are generally low level tests that are used to test specific methods or bits of functionality in your code.

I agree with the other answer that mentions testing public interfaces as this will help prevent regression. I would also suggest testing your protected or private methods as well though, to help ensure that what you expect to happen, is actually happening. This becomes more necessary as the code grows in complexity.

It's also worth noting the difference between unit tests and integration tests. Integration tests are used to test your integrations with other APIs or packages. An example would be testing code that employs an ORM to write and query data.

If you are struggling with what needs to be tested and what doesn't, I'd recommend coming up with some assumptions about what your specific pieces of code are supposed to do. For instance,

    public class BankAccount {

      public long Balance { get; set; }

      public void Withdraw(int amount){
        if(Balance >= amount) 
        {
          // Withdraw code here
        } 
        else 
        {
          throw new InvalidOperationException("Amount greater than balance");
        }
      }
    }

So, you could test that Withdraw function to ensure that proper amounts are withdrawn correctly and invalid amounts throw the proper exception. This is just an example but you get the idea. I'd suggest also looking into Test Driven Development (TDD), as it may give you some idea of what can or should be tested. As a disclaimer, I don't use TDD but it may get you thinking on the right track. Hope it helps.

0

You are agonising over a technique, rather than the goal.

The goal is: How will I know that the code has done something wrong?

Sometimes the answer will be: I wrote a unit test, and it is failing.

But other answers include:

  • I've analysed the algorithm and traced out every outcome, those outcomes precisely meet my understanding of the problem. Therefore the code cannot do anything wrong by my current understanding.
  • Small errors are tolerably, and big errors will be noticed/easily recovered from. (Such as a developer setup script).
  • An Audit trail is produced and analysed separately. Errors can be reversed. (such as DVCS repositories)
  • The public are beta testers, as long as we can switch a feature off... (like web apps)

  • etc...

or some mix there of...

The important part is the feedback. There is a mechanism that passes information back to the developer so that the code can be verified as working or improved upon.

That being said while feedback is better than no feedback, some kinds of feedback are better than others. Consider 2000 customers complaining vs. a red lit unit test. Which is the better feedback? In some cases it will be the 2000 customers because they can provide the right sort of feedback. In othercases it will be the unit test, because it can provide feedback sooner and of similar quality for a lower cost.

Chances are you will need several of these mechanisms each operating at different time scales. What precisely is the kind of feedback you need on this code? Figure that out, then support (and listen to) the right feedback sources.

Not the answer you're looking for? Browse other questions tagged or ask your own question.