3 ms·

In my previous job I was maintaining a big project which originally had zero unit-tests, it was apparently working well but once I started adding TDD I found se

In my previous job I was maintaining a big project which originally had zero unit-tests, it was apparently working well but once I started adding TDD I found several security issues, edge cases, and memory overflows; by the end of my contract I had written more than +2,800 unit and integration tests and the code coverage was still low at around 60% but I am very confident that new developers are going to take ownership of the project from the beginning without much training just because I wrote those tests. I consider testing an useful way to allow new contributors to join the development process because they will not be afraid to touch the code because the tests will throw a warning when something breaks after any modification, without tests they would surely have to spend more time checking the details of their modifications more than integrating into the team.

_RPM 10y ago
What was the definition of code coverage at your shop? Does it mean testing every line of execution?
- exception_e 10y ago
  He/she probably used a tool to capture the coverage %.
  - throwaway745234 10y ago
    That only rephrases the question to what definition the tool used.
  - _RPM 10y ago
    This comment reminds me of a typical response from a politician to a pressing question.
    - exception_e 10y ago
      Sorry for the very literal answer. I honestly thought you were interested in how the coverage was calculated. As an aside, I've worked on projects where coverage wasn't used and the rule was to "test the important bits" and I've also been on projects where coverage had to be >= ~98%. I wonder if a middle-ground approach would be effective.
- jondubois 10y ago
  Good point. I hate it when people write tests to cover every single function (to cover every line of code) but they pay almost no attention to the range of inputs/arguments passed to those functions. I think that most bugs in production can be traced back to "An unexpected argument which was passed to a complicated function/method" - According to this, you should focus your testing efforts on methods/functions that have complicated logic and you should test them with a range of unusual arguments/inputs. Writing tests for EVERY function/method using only obvious (common use-case) arguments is a waste of time.

_RPM 10y ago

What was the definition of code coverage at your shop? Does it mean testing every line of execution?

exception_e 10y ago
He/she probably used a tool to capture the coverage %.
- throwaway745234 10y ago
  That only rephrases the question to what definition the tool used.
- _RPM 10y ago
  This comment reminds me of a typical response from a politician to a pressing question.
  - exception_e 10y ago
    Sorry for the very literal answer. I honestly thought you were interested in how the coverage was calculated. As an aside, I've worked on projects where coverage wasn't used and the rule was to "test the important bits" and I've also been on projects where coverage had to be >= ~98%. I wonder if a middle-ground approach would be effective.
jondubois 10y ago
Good point. I hate it when people write tests to cover every single function (to cover every line of code) but they pay almost no attention to the range of inputs/arguments passed to those functions. I think that most bugs in production can be traced back to "An unexpected argument which was passed to a complicated function/method" - According to this, you should focus your testing efforts on methods/functions that have complicated logic and you should test them with a range of unusual arguments/inputs. Writing tests for EVERY function/method using only obvious (common use-case) arguments is a waste of time.