Why code review beats testing: evidence from decades of programming research

Re:Why code review beats testing: evidence from decades of p... by felipemnoa on Monday October 03, 2011 @10:39PM (#3069116)

>>10 minutes of looking over code by another developer will find more bugs than days of testing

I find this surprising. Unless you are talking about new developers. Automated test cases should be more than unit test cases. They should include system wide test cases as much as possible. i.e. For a game you would write test cases on the physics engine. The physics engine includes collision detection and collision response. Of course, you would also have test cases for each of those modules independently.

[ Parent | on HN ]

Re:Why code review beats testing: evidence from decades of p... by nl on Tuesday October 04, 2011 @12:24AM (#3069358)

in Code:

  static final String HELLO = "helo wolrd";
  ...
  out.println(HELLO);

in test:

  input = in.readln(); // yeah massively simplified, I know
  assertEqual(Code.HELLO, input);

pass.

But a developer will (should!) find the error immediately.

[ Parent | on HN ]

Re:Why code review beats testing: evidence from decades of p... by boyter on Tuesday October 04, 2011 @05:33AM (#3070088)

That's a bad test though. Its not brittle but assuming it was written in a Tdd manner there should be at least two chances for the developer to catch the bug if they don't use the constant they are testing in the test.

I have no source on this but isn't it bad practice to use constants in your tests? I personally use a new string with the expected value. It forces me to look twice and really consider what I am doing.

[ Parent | on HN ]

Re:Why code review beats testing: evidence from decades of p... by nl on Tuesday October 04, 2011 @05:46PM (#3073069)

It's a comment on hacker news illustrating a point, not a guide of how to write test cases.

The point is that it is possible to have good test coverage and still have bugs that are best found by humans.

[ Parent | on HN ]