4 ms·

I've noticed that code connectedness has a huge impact on the kind of test coverage needed. For example, if your website back-end is fairly stable and the API

I've noticed that code connectedness has a huge impact on the kind of test coverage needed. For example, if your website back-end is fairly stable and the API rarely changes, then you don't typically need 100% code coverage on each page. As you mentioned, if you fix a bug, it won't randomly break later... On the other hand, with a bunch of connected objects and events that fire, causing other events... it's very possible for a change in one system to affect others. In this situation, I recommend a ton of unit tests _and_ acceptance tests. In addition, decouple the components in the system and stabilize your base APIs. This will allow you to write a new feature without affecting stability elsewhere.

DrJokepu 17y ago
I also noticed that (at least in the code I write) bugs are much more prevalent in "boring code" than in "smart code"; that is, if I got some elegant but rather advanced piece of code I had put a lot of thought into (like some smart math stuff or something similar), it almost always works right away without any bugs whatsoever, however, boring and tedious-to-write code (such as wiring up GUI, integration glue code etc) tends to have a lot more bugs in it. Unfortunately, this first type of code is a lot easier to test automatically than the second type. Smart code usually has clean and simple interfaces, while writing tests for "boring code" is also boring and tedious, like writing a test for each textbox on a form etc.
- chadaustin 17y ago
  Maybe there's a way to automate the boring code? Write a system that lets you build UI without manually specifying the behavior of every control, etc.