TDD для системных программ

Question

Я пытаюсь практиковать TDD при написании программы, которая использует системные вызовы для записи кода в память других процессов, например, эквивалентные Windows вызовы API будут выглядеть примерно так:

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

I Я изо всех сил пытаюсь придумать, каким будет первый тест, так как здесь не так много logi c, кроме фактического написания кода тестируемым способом.

Я начал с создания класса вокруг системных вызовов, а затем просто издевался над ним и проверял, вызываются ли ожидаемые функции, но мне казалось, что я просто добавляю уровни абстракции для тестирования, а сами тесты мало что сделали но убедитесь, что вызовы были сделаны.

Ни одна из фактической функциональности, то есть сами системные вызовы, запись в память и c не тестировалась.

Я просто пытаетесь что-то протестировать со слишком маленьким логом c? Или что реальный тестируемый контент находится в трудном месте для тестирования (например, системные вызовы, взаимодействующие с ОС)?

Answer 1

Я просто пытаюсь что-то протестировать со слишком маленьким логом c?

Возможно. Если код, который вы пытаетесь написать, «настолько прост, что явно нет недостатков», то наличие набора автоматических детекторов ошибок не принесет вам многого.

С другой стороны, что-то необходимо решить, какой системный вызов сделать следующим, какие аргументы должны быть, и как справиться с непредвиденными обстоятельствами. По мере того как сложность этого элемента растет, преимущества автоматических детекторов ошибок возрастают. 1016 *, у вас будет достаточно четкое разделение проблем, и вы сможете отложить введение тестов на потом.

Когда позже? Либо когда вы начинаете получать обратную связь о том, что основной лог c имеет неочевидные недостатки, либо если вы чувствуете, что стоимость безопасного внесения изменений начинает компенсировать ваши затраты на тесты. На этом этапе также может иметь смысл создать новую реализацию ядра logi c с нуля, используя тесты.