m0rv4i
m0rv4i

Reputation: 435

TDD for Systems Programs

I am trying to practice TDD while writing a program that uses syscalls to write code into another processes' memory, e.g the equivalent Windows API calls would be something like:

CreateProcess(...);
VirtualAllocEx(...);
WriteProcessMemory(...);
CreateRemoteThread(...);

I'm struggling to come up with what the first test would be, as there isn't much logic, in addition to actually writing the code in a testable way.

I set off with creating a class around the syscalls then just mocking it and verifying that the expected functions are called, but it felt like I was just adding abstraction layers for the sake of testing and the tests themselves did little but verify that the calls were made.

None of the actual functionality, i.e. the syscalls themselves, writing memory etc was being tested.

Am I just trying to test something with too little logic? Or that where the real testable content lies in a tough place to test (i.e. syscalls interacting with the OS)?

Upvotes: 2

Views: 68

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57277

Am I just trying to test something with too little logic?

Perhaps. If the code you are trying to write is "so simple that there are obviously no deficiencies", then having a bunch of automated mistake detectors isn't going to buy you very much.

On the other hand, something needs to decide which syscall to make next, and what the arguments are supposed to be, and how to handle contingencies. As the complexity of that piece grows, the benefit of automated mistake detectors grows.

My guess: if you write your core logic using function pointers, and pass the various syscalls as arguments to your core logic, you'll have a clean enough separation of concerns that you can defer the introduction of tests until later.

When is later? Either when you start receiving feedback that the core logic has not-obvious deficiencies, or if you feeling like the cost of making changes safely is beginning to offset what you would need to invest in tests.

It may also make sense at that point to create a new implementation of the core logic from scratch, using tests.

Upvotes: 1

Related Questions