Managing your manager when it comes to legacy code

It is really nice because its chapters are arranged around specific problems you will encounter wrapping existing code in tests so you can easily find the write chapter via the table of contents.

Especially if you have to write them in COBOL.

After all what you really care about is the behaviour of the system. It can be counter-productive to unit test pieces of legacy code because you may end up refactoring things at a higher level and breaking all your unit tests.

If it's clear that a piece of the legacy system stands on its own as a "unit" and has reasonable interfaces then by all means add unit tests to that. The biggest value though IMO in a "legacy" system is to add system level tests. Those are often easier to put in than unit tests, will catch problems involving multiple components, and will teach you about how the system is supposed to behave.

Without looking at the book, a few things from Feathers I think about often:

- The concept of "sensing" is useful when thinking about test design. I alternate between state-based TDD vs. a more behaviorist/mockist style depending on whether the code's job is fundamentally about managing state, or routing requests to other components (a surprisingly useful distinction)

- Converting methods to "virtual" can be pretty useful when it's too hard to introduce an interface, but you want to mock/stub out a component

- "Sprouting" is a nice way to think about how a class can "Grow" out of existing code, same for methods and parameter clumps (from Fowler)

- It's also a darned humorous and funny book. "The case of the irritating parameter", "Help, this code just calls a bunch of other code", "This class is impossible to get under test", etc. I love the writing style and how he stops just short of hyperbole while still making me grin.

-- someone whose boss is king anti-midas: everything he touches is brittle duct-taped shit that breaks if you glance at it crosseyed. I just spent 4 hours looking for queries in our codebase to finally discover a bash script loads query templates from a sql db (completely non-source-controlled, naturally), seds parameters into them, and runs them, and of fucking course, doesn't escape quotes quite right...

In my experience, they were a developer for a couple of years 15-20 years ago and while they might think they're still a developer, they're generally more clueless than a manager who has no development background.

The absolute best manager's I've ever had were one's who still did at least some active development on the product. I know that's hard for a manager to fit in to a busy schedule but I really feel like there should be concessions made in the organization for this to happen.

- person two removes half the dishes and goes over them with a sponge or towel, then places them in the cabinet.

- person three removes the last of the dishes, goes over them with a sponge or towel, then places them in the cabinet.

Communism, it works on paper.

That prepares a manager for bad news.

Maybe this stuff is obvious and I just lack empathy, I dunno.

Hey, you don't want ads, we'll give you sponsored content...

This post advocates:

1) unit test everything

2) complain you can't change anything without breaking a lot

3) complain that the program doesn't work even when the unit tests say "it should".

Well that's pretty much the expected result, isn't it ? Of course unit tests break if you change a method, even if the resulting program works better. And a built program doesn't work if all unit tests pass ? Well that's just not what a unit test tests ... so of course it doesn't.

An alternative tactic could be:

1) understand the problem domain. Writing an administrative system ? You should be a better accountant than the worst accountant that works in that department. If a feature request comes in, and you can't answer "why do they want this", it's time to spend some time in their team.

2) get an integration test. Something that emulates the software doing what it's meant to do at a large scale with as many real components as possible. E.g. an administration system should just be asked to run an administration, and have the result checked. The result should be checked in the sense that it should match what the accounting handbook says it should say, NOT if the code worked as expected.

You should try to do realistic things. E.g. have the test read the production database, and then enter the first 50000 customers into the test in a random order, constantly doing things like getting a customer balance in between. Insert 10 test customers and see how their accounts evolve and if this matches business rules. Check if the total system still balances out to zero at every point. Have it load the system, demanding it performs at a minimal acceptable level.

3) change things.

4) find out what breaks on a functional level. Get a report that when adding the current customer list one at a time to the software, 5 weren't in the database after entering them. Fix.

5) Run the integration test again. It passes.

6) Confidently go to your boss and declare this software will work. You can say that, because you just have demonstrated that it works.

Some bad programmers hate this, because it finds problems unit tests won't ever find, and won't tell you where the problem is. They don't help programmers that don't understand what the program is doing. They don't directly report why things are happening. They won't let developers get away with "I just changed the part I understand", and don't let them mark the bug as fixed after that. Entering a new customer takes 50s after your field addition change ? Integration tests will find this, and create an easily debuggable situation. Integration tests will catch that code that is multiple directories and modules apart, maybe even separated by an RPC won't cooperate. Integration tests, in short, tell you that the program does what it's built to do.