Question

I have noted over the years, that I tend to write maybe a screen full of code, then test to make sure it does what it should.

Some of the benefits of this technique are

Syntax errors are a result of the new code, so you don’t have to look far to find the cause.

It is cheap to set up a temporary condition, that lets you test the else clause of an if statement, so you can be sure to get error messages, and the like correct when they are cheap to test.

How do you tend to code?
What benefits do you get by doing it that way?

EDIT: Like most of my questions, I really haven’t set the context well enough. I am not really talking about unit test level granularity. I am referring to making sure the local bit of code does exactly what I intend it to, at the time of implementation.

Answer 1

I tend to code until I have something that should produce a well-defined observable behavior. Usually, this is a single public API function, sometimes a full class. This also encourages me to break down the problem into small functions with well-defined observable behavior. Most of my functions are smaller than a full screen. If a function is too complex to test, then it’s probably badly designed from other perspectives anyhow.