Even statement coverage can be tricky if you're trying for real just-test-this-unit unit tests. At least, in static languages they can.
For example; say you want to test a class which parses text fields in a database. You add exception handlers for problems while connecting to and reading from the db. To get a proper unit test, you need to create a mock db object with Connect() and Read() methods, which throws all the different flavours of exception you'd want to handle. Writing that mock object may well be much more complicated than the object you're trying to test, and more error prone.
My experience has been that full-fat unit tests can take an awfully long time, and it's not clear to me that a developer always gets the right bang for his buck over the course of the project.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
For example; say you want to test a class which parses text fields in a database. You add exception handlers for problems while connecting to and reading from the db. To get a proper unit test, you need to create a mock db object with Connect() and Read() methods, which throws all the different flavours of exception you'd want to handle. Writing that mock object may well be much more complicated than the object you're trying to test, and more error prone.
My experience has been that full-fat unit tests can take an awfully long time, and it's not clear to me that a developer always gets the right bang for his buck over the course of the project.