1

I'm kind of new to unit testing so please excuse a naive question.

I've heard the idea of not testing anything that has a cyclomatic complexity of 1. This is interesting to me b/c I do a lot of interaction testing between events. For example, button is pressed, fires an event, raises event on presenter, presenter modifies the model, and presenter calls method on the view. So I test to make sure that when the button event is raised, the right method on the view is called.

Each method in this sequence may have a cyclomatic complexity of 1. There is no branching. But if I want to test it as a "system" (i.e. view, presenter, model) cyclomatic complexity is higher -- adding up all the 1-valued methods in the event sequence.

So my question is when people suggest that I don't need to test methods that have a cyclomatic complexity of 1, are they not talking about interaction tests for testing interactions between classes like I've described above?

I've come across this idea twice this week - once in a Mark Seemann Pluralsight video and once here: http://webquali.com/blog/67/15-ways-to-write-beautiful-code.html.

Trevor
  • 4,620
  • 2
  • 28
  • 37
  • While it can be interesting discussion I don't think it fits SO format. – Lanorkin Mar 26 '17 at 05:29
  • This is rather dogmatic (and offtopic for StackOverflow since it is primarily opinion-based). That said, if you cannot see the value of a test against the method itself, that is typically indicative of an area where a) an integration test is more useful or b) you should "unit test" a method or two higher in the stack without being a true integration test if it can be completely encapsulated without external dependencies. – David L Mar 26 '17 at 05:34
  • As for question consider for example method having 1 as cyclomatic complexity `int Multiply(int a, int b) { return a - b; }` - it's plainly wrong - why would not you test it? I think you should not go from "now it is simple method - I would not test it", but rather from "I should test method contract anyway no matter what body it has" – Lanorkin Mar 26 '17 at 05:34
  • Thanks. Looks like the answer is yes you should. Lanorkin gives a good example. I understand now that the answer is not cut and dry. And that is all the answer I need. – Trevor Mar 26 '17 at 05:53

1 Answers1

2

Think of tests not in terms of prescriptive TDD, but as a harness that allows your developers to find out if the unexpected change in behaviour happens when your CI runs the integration.

As a simple example you were provided in comments, for a calculator method:

public int Minus(int a, int b) => a - b;

Not writing a unit test for it may result in someone accidentally changing the code like so:

public int Minus(int a, int b) => a + b;

which would inevitably break the whole app at runtime.

So typically the recommendation would be: for each line of code written by developers in your team where someone wrote it, there should be a corresponding implicit or explicit assertion.

When we say implicit assertion, we mean, for example:

public object ReturnMytype() => new MyType { MyProperty = "a" };

[TestMethod]
public void ReturnMytype_SetsMyPropertytoA(){
   Assert.AreEqual("a", (new MyClass().ReturnMytype as MyType).MyProperty);
}

In the above unit test the assertion that ReturnMytype returns correct type is implicit (typecast). This one test is sufficient to assert both behaviours of method under test - that it returns a MyType and that it sets MyProperty to "a".

zaitsman
  • 8,984
  • 6
  • 47
  • 79