2025 Public Training Schedule
June 23 26, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
July 22 – 25, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2025 To Be Agile
- July 4, 2018
- Bits and Pieces
Well, happy Independence Day.
Functional independence is one of the key characteristics of testable code so I thought it fitting to discuss today. We want to make each piece of our code as functionally independent as possible and make those pieces as small as possible. This is not always easy to do but most of the time it’s the right thing to do. Code that is functionally independent is more straightforward to verify and to extend.
But a lot of code is not functionally independent. A lot of code is intertwined with itself and nearly impossible to break apart. A lot of code depends on global state and therefore can be very difficult to test. Sometimes we have to use global state but if we can avoid it then we should. Again, good unit tests are functionally independent of each other so they should have no dependencies on anything external to the test itself.
The constraints around writing good functionally independent and testable code are the same constraints for building maintainable software. When code is functionally independent it’s far more straightforward to test and, because it injects its dependencies, new versions can inject new variations of dependencies and therefore extend the system in a very safe and effective way.
Independence in code means less concrete coupling and more abstract coupling. Much of this is about separating out what we do from how we do it. The features that we present should provide what they do but should provide others as little implementation details as possible because the more that we can hide the freer we are in the future to change those implementation details without affecting other parts of the code that depends on it.
There are many ways to separate out the “what” from the “how” and much of the art of computer software development is based on this. It’s about how we abstract and think about problems and then how we model them in code so that they’re understandable to us as well as functional in a computer program.
Independence and software is a good thing because we want to compose complex behaviors from simpler behaviors and we want to do this because each of the different layers can be tested independently. Small tests tend to be simpler tests so we like to test things at the unit level rather than testing things that the integration or system-level. The unit tests also run a lot faster than integration or system tests.
Independence in software is a good thing, it’s a virtue. The more independent we make our code the more straightforward it is to verify and the fewer dependencies are required in order to test it. This helps us build code in functionally independent components and make software more standalone.
Previous Post: « Introducing TDD to Managers
Next Post: The Agile Community »