[burrows]

My first comment was specifically about the invocation of “entropy”, which I believe is just confusing nonsense. And as I said I don’t have the requisite background to really make the point, was hoping for some goodwill and assistance perhaps.

I’ll retract my comment about formal methods since I’ve never actually used them in a refactor. And I agree that tests make refactoring easier. But none of this demonstrates for me that tests are the “best” tool for facilitating a refactor.

And so, what specific quality guarantees do good tests make?

[Jtsummers]

It's not really nonsense, it fits a common notion of entropy: lack of order or predictability; gradual decline into disorder.

As software systems (like many systems) go from initial development (which may or may not have a solid vision and initially highly disciplined development approach) to long term maintenance, disorder creeps into the system. Often just as a matter of expedience, "Let me make this field public so this other module can modify it directly because I need it now, I'll come up with a proper interface later. Oh shit, three years later 100 modules are making use of that public field."

What tests do, in this case, is help to preserve order. They help to ensure that a more rigid and ordered structure for the code remains. Formal methods only take you so far because, outside of maybe coq and related languages, there is no direct connection between your formal method spec and the code that has been written, in contrast to tests (which can be derived from your formal spec, but usually manually). Of course, tests can only carry you so far, they also have to be maintained. If a test is removed because it's no longer relevant, is another test put in its place to verify the new system? Are tests disabled because they're only failing sporadically or because the bugs they represent are hard to fix and we don't know how to yet (or don't have the time)?

Gradually, a system starts to suffer from various problems of this sort, that's entropy. Maintaining quality is a constant struggle against various forces (convenience, loss of institutional knowledge, time pressure, etc.). Tests are one way (and a critical way) to help balance against those forces.

EDIT: Other formal methods that work with real systems would be in Ada/SPARK, ATS, or Frama-C and I'm surprised I didn't mention them above. However, at least with SPARK, it narrows the scope of what you can do with the system and prove properties about it. That scope is always increasing, but is still a subset of what Ada itself can do. That's not all bad, but this means you can only consistently prove (in a formal sense) properties of subsets of a larger system and will likely be unable to prove (in an automatic fashion at least) a significant number of properties of those same larger systems.

[majkinetor]

Lets check out wikipedia:

Entropy is a scientific concept as well as a measurable physical property that is most commonly associated with a state of disorder, randomness, or uncertainty

What is your claim, that disorder, randomness and uncertainty DO NOT build up with time? :)

> And I agree that tests make refactoring easier.

They don't make it easier. They make it POSSIBLE.

> And so, what specific quality guarantees do good tests make?

Good tests cover all critical sections of functional specification (what is deemed critical depends on project). If you have functional rules x, y and z somewhere there, there need to be bunch of tests for x, y and z somewhere, ideally fuzzy, fast and without blank database.

This is all very much basic IT stuff for long time, particularly nowadays when software needs to run not only in your basement but on every conservable device and number of different contexts!

No offense, but you seem new in this business, and your aggression doesn't help at all.

[kaba0]

The topmost claim was that software quality degrades over time, as entropy must increase. Both of these claims are false, as the topmost commenter did actually say correctly - entropy only grows globally, but it is possibly to decrease it locally at the expense of some larger increase somewhere else (think of a fridge - it decreases the randomness of molecules inside (cooler) by heating the outside).

If we accept this analogy, then with enough care, a software project can improve in quality (paying off technical debt for example, or extensive code reviews by experts). But even letting go of this possibly flawed analogy, while there is a tendency of entropy-build up, very easily observable in my home folder, there exist software projects that do improve in quality over time.

[throwaway1777]

The idea is that entropy increases unless you put in energy. If you are specifically working to keep the code clean of course that’s possible. But entropy, bit rot, etc is the default state without any work being put in to combat it.

[Jtsummers]

And putting "energy" (people, time, money) into it isn't even enough on its own. I've seen plenty of 9-10 figure projects that were still suffering due to a lack of proper focus.

[majkinetor]

Those must be rare like unicorns :)

I don't deal with academic theory and strange special cases - I deal with real, everyday world. You can basically argue out any position if you are clever enough but that doesn't prove anything except that you are clever.

[burrows]

> What is your claim, that disorder, randomness and uncertainty DO NOT build up with time?

It depends on the system. Claiming that disorder builds up in all systems is false, afaik. From a Google search: Entropy increases in a closed system. In open systems, the entropy is kept low, or decreases

Are you claiming that codebases are closed systems?

> They don't make them easier. They make them POSSIBLE.

Are you arguing about the definition of “easier” or just trying to rhetorically emphasize the impact of tests on refactoring?

Would you agree if I said tests make refactoring A LOT easier?

Seems like we both agree that we’d rather refactor a system with tests than without (all else the same).

> Good tests cover all critical sections of functional specification (what is deemed critical depends on project). If you have functional rules x, y and z somewhere there, there need to be bunch of tests for x, y and z somewhere, ideally fuzzy, fast and without blank database.

You’ve told me what parts of the code you want to test, but not what guarantees the tests make.

> No offense, but you seem new in this business, and your aggression doesn't help at all.

You’re right I’m new. Thanks for your patience.