99% code coverage (2017)
The industry is obsessed with getting 100% unit test code coverage even though it doesn&#x27;t mean anything to the project.
The purpose of unit tests is to lock down the project&#x27;s source code once it&#x27;s essentially completed; to avoid regressions when making minor changes.<p>If you start writing unit tests too early in the project, you&#x27;re effecively locking down units of code which haven&#x27;t yet proved themseves to be useful to your project.
If you build square wheels for example, you may not realize that they&#x27;re not designed correctly until you attach them to the car and realize that the car doesn&#x27;t function well with them.
It makes no sense to preemtively write unit tests for a component which has a very high likelihood of not being in its final desired state; you&#x27;re just giving yourself more work to refactor the unit tests over and over; or worse, you&#x27;re afraid of refactoring the tests and so you lie to yourself thinking that square wheels are fine.<p>Integration tests are by far the most useful tests to have at the beginning and middle stages of the project; integration tests allow you to keep your focus on the real goals of the project and not get stuck on designing the perfect square wheel.