How do you achieve 100% test coverage?

When doing Test-Driven Development, one critical metric is test coverage. And it is often quite difficult to achieve 100% test coverage on a given method using its "normal" unit tests.

This can often lead to very strange looking test code written specifically to test all possible branches and every corner case. Sometimes this is useful, but more often than not its testing for testings sake.

But if your test suite is good enough and tests all the designed behavior, uncovered code is a good indication of unused code. Try to delete it. If it still compiles and all tests pass, the code was dead weight code you can safely remove.

This is specifically often true for getters and setters for each and every attribute on a particular class. Put YAGNI (You Ain't Gonna Need It) to use and remove all setters and getters not in active use by your code. If you need one later, you could always add it. This makes the code much more compact and easier to read.

But what if the getters and setters are part of an API? Well, then the API should be an interface, shouldn't it?

Om å sette sammen et godt team

Building a software team: Making room for different:

We all know that everyone is different, and yet we go on treating software engineers as interchangeable, plug replaceable units. You can hear it in the management jargon: we talk about resources when we mean people, about full time equivalents, about needing a architect, two mid-levels and a few grunts. Well guess what: it really doesn't make much difference which architect you pick, which full time equivalent you use, what particular resources you move onto a project. It is just the difference between success and spectacular, debris spewing failure. I'm not talking about good people vs. bad people here: you not only need good people to succeed, you need the right good people.