Sensing and Separation
When working with legacy systems, you need to be able to determine where to draw lines within your system. Feathers addresses this with the topics ‘sensing’ and ‘separation’. This will be critical tools when breaking down your monolith, as well as preventing further technical debt. Today, we will talk about sensing.
Sensing – Breaking down the path of your dependencies to sense when we cannot access values our code affects.
There are various methods to ‘sense’ calculation in your code:
Fake Collaboration – Impersonate a collaborator of your class. In short, write a fake object to allow you to override functions you would have otherwise not have access to.
An example of this would be if you were working on the code to display the time inside the cluster of your car. You may have high level access to the functions at the top of the code, say the bus that talks to the cluster. The method that actually displays the time inside of that cluster may not be accessible easily, buried deep within the cluster functionality.
To navigate this, you can write your own display code, and overload the method that is needed to display the time within the cluster class. This way, when called during your tests, you can confirm that the expected results of whatever time would be correctly displayed. Examples would be Military Time, Daylight Savings calculations, etc.
This may seem overly simple, and some developers may think this is poor form – but remember that this may be the best you can do in some legacy systems. Fake object support real tests.
Mock Objects – Rather than writing fake objects, many languages now have supporting libraries for mock objects. We will not necessary manipulate the calls within a fake object, we will use the provided tools to ask a mocked object what calls it received and what parameters were within those calls.
If we go back to the example above, rather than writing a display object where we overload a method, we simply mock the the object and ask (with the inputs we setup) if the correct methods were called with the correct parameters. There has been large development in this area in the past few years, and there are may tools depending on your language:
- Java Mocking Framework – Mockito – https://site.mockito.org/
- C++ Mocking Libraries – Isolator – https://www.typemock.com/isolatorpp-product-page/
- Python Mocking Libraries – Python contains it’s own mocking libraries – https://docs.python.org/3/library/unittest.mock.html
We need to remember that while we have these libraries easily accessible in newer languages, older systems (such as one of my FORTE applications) do not give you this ability.
Summary
When we start the discussion on legacy IT applications, we need to think of how we can break these systems down. How do we separate areas where we might have issues, or be able to upgrade with newer technologies? We will look at sensing and separation. I would liken this to trying to pull apart a flannel shirt, we using sensing to find where we might have loose threads, and separation to pull the thread apart to replace an entire piece of the shirt. We will touch on separation in the next post.