Fake Objects Support Real Tests Sometimes when people see the use of fake objects, they say, “That’s not really testing.” After all, this test doesn’t show us what really gets displayed on the real screen. Suppose that some part of the cash register display software isn’t working properly; this test would never show it. Well, that’s true, but that doesn’t mean that this isn’t a real test. Even if we could devise a test that really showed us exactly which pixels were set on a real cash register display, does that mean that the software would work with all hardware? No, it doesn’t—but that doesn’t mean that that isn’t a test, either. When we write tests, we have to divide and conquer. This test tells us how Sale objects affect displays, that’s all. But that isn’t trivial. If we discover a bug, running this test might help us see that the problem isn’t in Sale. If we can use information like that to help us localize errors, we can save an incredible amount of time. When we write tests for individual units, we end up with small, well-understood pieces. This can make it easier to reason about our code.
Mock Objects
seam = 'đường may'
f you are changing it today, chances are, you’ll have a change close by pretty soon. When I work with teams, I often start by asking them to take part in an experiment. For an iteration, we try to make no change to the code without having tests that cover the change. If anyone thinks that they can’t write a test, they have to call a quick meeting in which they ask the group whether it is possible to write the test. The beginnings of those iterations are terrible. People feel that they aren’t getting all the work done that they need to. But slowly, they start to discover that they are revisiting better code.
It Takes Forever to
Make a Change
How long does it take to make changes? The answer varies widely. On projects
with terribly unclear code, many changes take a long time. We have to hunt
through the code, understand all of the ramifications of a change, and then
make the change. In clearer areas of the code, this can be very quick, but in
really tangled areas, it can take a very long time. Some teams have it far worse
than others. For them, even the simplest code changes take a long time to
implement. People on those teams can find out what feature they need to add,
visualize exactly where to make the change, go into the code and make the
change in five minutes, and still not be able to release their change for several
hours.
Let’s look at the reasons and some of the possible solutions.
Understanding
As the amount of code in a project grows, it gradually surpasses understanding.
The amount of time it takes to figure out what to change just keeps increasing.
Part of this is unavoidable. When we add code to a system, we can add it to
existing classes, methods, or functions, or we can add new ones. In either case,
it is going to take a while to figure out how to make a change if we are unfamiliar with the context.
Comments
Post a Comment