c++ - TDD用于系统程序

标签 c++ tdd

我正在尝试在编写使用syscall将代码写入另一个进程的内存的程序时练习TDD,例如等效的Windows API调用将类似于:

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

除了要以可测试的方式实际编写代码外,由于没有太多逻辑,我正在努力提出第一个测试的内容。

我开始围绕syscalls创建一个类,然后对其进行模拟并验证是否调用了预期的函数,但是感觉就像我只是为了测试而添加抽象层,并且测试本身没有做任何事情,但验证了调用是否制作。

没有测试任何实际功能,即系统调用本身,写入内存等。

我只是在尝试以太少的逻辑来测试某些东西吗?还是真正的可测试内容位于难以测试的地方(即与操作系统交互的系统调用)?

最佳答案

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



也许。如果您要编写的代码“太简单了,显然没有缺陷”,那么拥有一堆自动错误检测器将不会给您带来很多好处。

另一方面,需要确定下一步要执行的系统调用,参数应该是什么以及如何处理突发事件。随着复杂度的增加,自动错误检测器的优势也随之增加。

我的猜测:如果您使用函数指针编写核心逻辑,并将各种syscall作为参数传递给核心逻辑,那么您将有足够清晰的关注点分离,可以将测试的引入推迟到以后。

什么时候以后?当您开始收到有关核心逻辑没有明显缺陷的反馈时,或者您觉得安全进行更改的成本开始抵消您需要在测试上投入的资金时,要么。

在那时,使用测试从头开始创建核心逻辑的新实现可能也很有意义。

关于c++ - TDD用于系统程序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/62431659/

相关文章:

c++ - 动态控制c++数据结构中的成员数量

ruby-on-rails - Rspec & FactoryGirl 验收验证

python - 测试 Django 信号的正确方法

mvvm - 找不到在软件开发中应用最佳代码设计技术的最佳方法

ruby-on-rails - 如果我已经有一个没有任何测试的大型代码库,如何开始编写测试?

ruby-on-rails - 有效的 TDD 策略包括哪些部分?

c++ - 为什么在选择排序中使用 Xor 运算符交换对象不起作用?

c++ - 是否在重载的运算符删除函数中隐式调用了析构函数?

c++ - C++中的虚函数实例化有什么区别?

c++ - 是否可以以编程方式设置 gdb 观察点?