How to avoid brittle code

Re:How to avoid brittle code by crdoconnor on Monday March 28, 2016 @09:02AM (#11373976)

>The faster your test suite, the more often you can run it, and the faster you get feedback on your code.

In all likelihood, the faster it is, the more tightly coupled it will be. You're simply exchanging computing power for brain power (refactoring tests when you refactor code), which is nearly always a bad trade off.

[ Parent | on HN ]

Re:How to avoid brittle code by glenjamin on Tuesday March 29, 2016 @07:48AM (#11380790)

Usually my unit tests are tightly coupled to the module they're testing, but the modules themselves are loosely coupled from the rest of the system.

In most cases I want to preserve existing behaviour, so I don't want any existing tests to fail.

I'll add tests for the new behaviour in the relevant modules, add code to make them pass, and then if necessary update the glue code / integration tests which cross the boundary.

Pretty much by definition, a refactor of code should not change its behaviour. My tests usually assert on behaviour observed at the boundaries of modules, so they should still pass during refactorings.

[ Parent | on HN ]

Re:How to avoid brittle code by dllthomas on Friday April 01, 2016 @12:53PM (#11406357)

> Pretty much by definition, a refactor of code should not change its behaviour.

Quite precisely by definition, perhaps for other reasons as well :-P

> My tests usually assert on behaviour observed at the boundaries of modules, so they should still pass during refactorings.

I find the kind of refactoring that most desperately needs the support of tests is changing the boundaries of the individual units. Unit tests can still arguably be useful there in making me clarify the changes I'm making to my interfaces... but they do need changing, and I can't be quite as confident that nothing is breaking if I'm changing both code and tests in tandem.

[ Parent | on HN ]