Tip:
Highlight text to annotate it
X
Let's go through the answers, shall we? Male: Yeah, okay.
Refactoring should not cause existing tests to fail. Hmm. Well,
gee, if you're testing the, if you have some code that has
existing tests, and those tests rely on the current structure of
that code, and you change the way that that code is structured.
For example, maybe you change which arguments are passed, or
which order they're passed in, or maybe you rearrange methods in
such a way that results in the names of things changing. There's
every reason to believe that that might cause some of your tests
to fail, and that's okay. Remember that the goal is to have
working tests, working code, as often as you can, but it's
pretty much inevitable that if you've got tests and code that go
together, and you're going to change the code, there are some
cases where you cannot avoid temporarily having some of those
tests fail. Now as soon as that happens, your next step in
refactoring is figure out what you change, and figure out how to
adjust the test or the codes, so that your tests go green again,
which means that refactoring often results in changes to the
test suite. So the bottom statement in blue is clearly true.
Results in fewer total lines of code? Not necessarily, although,
as I've been discovering with my big refactor, in this case,
I've improved the structure so much that it actually is getting
shorter. And what about, it addresses explicit versus implicit
customer requirements? It could go either way, right?
Refactoring we're talking about pretty low- level stuff. The
code paths that you're using could be part of explicit or could
be part of implicit customer requirements. But the one true
statement in here, absolutely, is that it often results in
changes to the test suite, because when you change the structure
of the code, often you've got tests that were making assumptions
about that structure, and they'll have to change as well. And
the way you know that, is that they start failing.