March 7, 2007 at 14:05
· Filed under 测试, 软件工程, cpp
另一个文件使用 boost::thread boost::test
#include < boost/test/auto_unit_test.hpp >
#include < boost/thread/thread.hpp >
#include < boost/bind.hpp >
#include < windows.h >
#include < iostream >
int count = 0;
boost::mutex mutex;
void increment_count(int i, int j)
{
boost::mutex::scoped_lock lock(mutex);
count++;
Sleep(30);
std::cout << "count = " << count << " i= " <
}
BOOST_AUTO_TEST_CASE( thread )
{
boost::thread_group threads;
for (int i = 0; i < 10; ++i)
threads.create_thread(
boost::bind(&increment_count,i,i+1));
threads.join_all();
}
Permalink
March 7, 2007 at 13:07
· Filed under 测试, 软件工程, cpp
boost test 免连接link
//如此顺序，才可以保证多个文件的test case ，可以在release版本运行正确
#define BOOST_AUTO_TEST_MAIN
#include < boost/test/auto_unit_test.hpp >
#include < boost/test/included/unit_test_framework.hpp >
BOOST_AUTO_TEST_CASE( test1 )
{
BOOST_CHECK( true );
}
BOOST_AUTO_TEST_CASE( test2 )
{
BOOST_CHECK( true );
}
Permalink
October 2, 2006 at 21:57
· Filed under 测试, 算法
在Profile对话框中指定选项
若你选择了Funciton timing、Function coverage或Line coverage选项，则你可以在Advanced settings中指定进一步的范围，比如：你希望Profile只分析SampleApp.cpp文件中特定范围内的代码，可以在Advanced settings中填入， /EXCALL /INC SampleApp.cpp(30-67) 。又如：你希望file1.obj和file2.obj不参与分析，则可以在Advanced settings中填入， /EXC file1.obj /EXC file2.obj 。再如：你希望只描述指定函数，则可以在Advanced settings中填入， /SF ?SampleFunc@@YAXPAH@@ ，紧跟SF参数的是特定函数的修饰符名，获取该名称的最简单的方式是在创建项目时生成的MAP文件中查找。
SF，EXCALL，EXC，INC都是PREP的命令行参数，有关其他参数的详细说明可以通过在命令行提示符输入PREP /H得到。
Permalink
September 30, 2006 at 8:19
· Filed under 测试
Permalink
September 30, 2006 at 8:19
· Filed under 测试
昨晚看了一些关于tdd的文章，很有感触。
有一个聪明人提出了软件熵（software entropy）的概念：一个程序从设计很好的状态开始，随着新的功能不断地加入，程序逐渐地失去了原有的结构，最终变成了一团乱麻。
有些代码已经混乱不堪了，可是我们为何不去清理它们呢？我们担心会破坏它们。但如果我们拥有测试，我们就有理由确信这些代码不会被破坏，或是说我们可以很快的就找到被破坏的地方。
如果我们有了这些测试，我们就对代码发生改变无所忌惮。如果我们看到混乱的代码，或是一个不清晰的结构，可以毫无顾虑地清理它。
因为有了测试，代码重新变得易修改了；因为有了测试，软件重新变“软”了。
如果你曾有过增加单元测试到一个可以工作的系统中的经历，你会发现那一点儿都不好玩。你很可能会发现想跑通测试，你一定是要么去改变系统中的部分设计，要么就在测试上作假。这是因为你试图去测试的系统并不是基于可测试设计的。例如，你想要测试某个函数f。然而，f调用了另外一个从数据库中删除记录的函数。在你的测试中，你不希望这条记录被删掉，但却没有办法来阻止它。这样的系统就不是基于可测试设计的系统。
当你遵循TDD的三条规则的时候，你的所有代码天生就可测试！而且另一个能形容“可测试”的词汇就是“可解耦”。为了单独的测试一个模块，你就必须把它解耦。所以TDD强制你去解耦这些模块。确实，如果你遵循这三条规则的话，你会发现你可能比起从前来能做出更多的解藕。这就强制了你去创造更好的，低耦合的设计。
一旦你有了一个测试，你就要一直确保其正常工作，以检验你所加入的新的工作代码。不要每隔几天或最后才运行测试，每天你都应该运行一下测试代码。这种投资很小，但可以确保你得到可以信赖的工作代码。你的返工率降低了，你会有更多的时间编写工作代码。
使用JUnit后，花在调试的时间就会更少，在改变代码的时候更有信心。有了这种信心，你可以在重构代码，添加新特性的时候更有闯劲。如果没有测试，那么重构或者添加新特性很容易成为妄想，因为你无法知晓什么地方会被破坏掉。如果拥有完善的测试套，在改变代码后，立即运行测试，这样就可以得到信心，你的改变没有破坏任何东西。
当运行测试时，如果检测出bug，因为代码在脑海里还很清楚，所以bug很容易被解决。用JUnit编写测试，可以使你的代码编写达到极限速度，而且快速定位bug。
单元测试通常不测试很简单的代码，一般也不测试“边界代码”。很简单的代码容易理解，例如Get/Set函数，这里解释一下“边界代码”。“边界代码”是指用于与外部系统交互的代码，例如用于处理用户界面的代码。数据库、文件、网络都可以看作是外部系统，用于读写数据库或文件、或访问网络的代码也可以看作是“边界代码”，这类代码应该独立出来，可以进行单元测试，但对这些代码的单元测试通常不能自动验证预期输出，而是需要人工察看。编程时，不要把普通代码与“边界代码”混在一起，例如，不要把各种运算直接写在界面类中，做到了这一点，绝大多数代码都可以进行单元测试。
Permalink