Move the Patient into the Surgery

Part 1 of 4 learning hours on this topic. All are specific for the C language.

Learning Goals

Session Outline

Connect - what stops you writing tests?

From this list, pick your top three reasons for not writing unit tests:

Concept: Surgery

Hopefully in the connect part someone mentioned that they struggle with dependencies that make the code hard to test. In my experience with C code, it often comes up. You can just say that if nobody picked it :-)

The ‘surgery’ technique is a concrete way to identify and get control of dependencies using link-time substitution.

Show the starting code for Grep with Marketing. There are two CMake projects. One for the main (production) code, and the other for the surgery. The idea is to keep the main production build running and able to be deployed, while moving the part of the code we want to test into the surgery. This is the code we call the ‘patient’. In the surgery we can work on writing tests for the patient and refactoring it to be testable. When everything is ready we can move it back into the main build along with the new unit tests.

In this learning hour we’re just going to practice moving a patient into the surgery while keeping the main build passing.

Concrete: Move the patient

Follow the steps in the README file. You’ll know you’ve succeeded when the main build passes and the surgery build also passes.

Conclusions: What are the steps?

In pairs, copy the list of steps you used to take to get a patient into the surgery from the README. Edit as necessary so you understand what is meant. Put a star by the most important step(s). Put a question mark by any that you think could be done in a different order or which you think might be optional. Put a cross by any step you made a mistake in when you did it today.