单元测试应用指南(GTest,CPPUnit, OCUnit)

简介: 转载请注明出处:http://blog.csdn.net/horkychen  (以前写的资料,不准备翻了。) Index 1. Introduction 2.

转载请注明出处:http://blog.csdn.net/horkychen  (以前写的资料,不准备翻了。)

Index

1. Introduction

2. Purpose

3. Basic concepts of Unit Test

3.1 Suite

3.2 Test Case

4. Target programming languages

5. Target Unit Test Framework

6. Google Test

6.1 Google Test for Windows

6.1.1 Install the Google Test

6.1.2 Apply Google Test in your project

6.2 Google Test for Mac OS

6.2.1 Install the Google Test

6.2.2 Apply Google Test in your project

6.3 Supported Test Macros

7. CPPUnit

7.1 CPPUnit for Windows DDK

7.1.1 Install the CPPUnit

7.1.2 Create new project in WDK.

7.2 Supported Test Macros

8. OCUnit

8.1 Overview

8.2 Sample to add unit test

8.3 Supported Test Macros

9. Guideline to apply unit test

9.1 While one bug is found (Core module)

9.2 While new design is requested

10. Reference

 

  

1. Introduction

Different platform has different Unit Test framework, which depends on the development mythology.In xUnit framework, JUnit is best popular one, it supports many powerful features to allow programmer could write test case easily. For other unit testing framework, they all try to keep same architecture with JUnit, so all of them have many core value and common concepts.

2. Purpose

Application of Unit Test could improve the development quality entirely. The document is used to introduce how to apply unit test in the project, and help to write testing case easily in your project.

To apply Unit Test as regression testing is useful for current situation. While there are some bugs was found in core module, so the unit test is suggested to create regression testing. For UI operation, that could be identified as block box issue and test with Automatic Testing Mechanical.

Unit Test will be integrated with main project and build together. The unit test will be modified while new core issue is found. For some testing case will generate output files, that need confirmation manually. Anyway, that won’t affect the unit test application.

In this document, three unit test framework are introduced. Google Test and OCUnit is preferred for generally testing purpose. For Mac OS, even though XCode provide CPlusUnit as default C++ Unit Test framework, Google Test still is preferred for C++ Unit Test, that’s because Google Test has qualified maintenance from Google, and more useful links and documentation on Internet. The most important point, Google Test has better platform independent capability.

3. Basic concepts of Unit Test

 3.1 Suite

      One suite involves one or more test cases. Generally, it has below running cycle:

      “Set up” is called before running of each test case to initialize or reset the testing target.

      “Tear down” is called after running of each test case to clear testing target, such as allocated memory or instances.

 

 3.2 Test Case

      One test case is implemented as a single function in suite, it will perform one or more testing in a series. Each unit testing frame supplies many assertions to check the performing result.

 

Below is a table which list several test macros in Google Test, OCUnit and CPPUnit:

Google Test

OCUnit

CPPUnit

EXPECT_EQ

STAssertEquals

CPPUNIT_ASSERT_EQUAL

EXPECT_TRUE

STAssertTrue

CPPUNIT_ASSERT

EXPECT_FALSE

STAssertFalse

CPPUNIT_ASSERT_ASSERTION_FAIL

EXPECT_THROW

STAssertThrows

CPPUNIT_ASSERT_THROW

EXPECT_FLOAT_EQ

STAssertEqualsWithAccuracy

CPPUNIT_ASSERT_DOUBLES_EQUAL

 

 

4. Target programming languages

      C/C++

      Objective – C

 

5. Target Unit Test Framework

      Google Test for C/C++

      OCUnit for Objective-C (Cocoa Framework)

      CPPUnit for C/C++

 

6. Google Test

Google testing framework is a C/C++ unit testing framework which be hold by Google. That is base on xUnit architecture, and supports automatic test discovery.

 

Google Test should be downloaded from its website and compiled by developer own. There are two libraries and several header files are generated for further application.

  gtest library (gtest.lib in Windows, and libgtest.a in Mac OS)
    This is the main library of Google Test framework. All testing project should link with this library.
  gtest_main library (gtest_main.lib in Windows, and libgtest_main.a in Mac OS)

  This library provides the main function, so developer won’t implement it again. The main function is very simple also; you could find codes it in gtest_main.c.

 

There is only one header file needs to include in source code, below line should be added in testing unit:

 #include

*Remember to specify the search path for your header files.

 

6.1 Google Test for Windows

6.1.1 Install the Google Test

Step 1. Download the source code and extract all files.

Step 2. Open the Visual Studio solution inmsvc subfolder in downloaded gtest. Finish the converting wizard if open with newer Visual Studio.

 

Step 3. Compilegtest and gtest_main project.  Below files are generated in gtest/msvc/gtest/Release folder:

gtest.lib,

gtest_main.lib

 

And, header files are placed in gtest/include folder. For easily use, you could put them together as below structure:

gtest/

  /include

  /lib

 

6.1.2 Apply Google Test in your project

One Fibonacci number program will be created to introduce application of Google Test. For implementation of Fibonacci number will be ignored, we just create one command line tool and name source file and class as Fibonacci. Below steps is shown how to add Google Test base on this project.

 

Step 1. Add one new Win32 Console project in the solution, and name as “UnitTest”. Remove the main function in UnitTest.cpp.

 

Step 2. Add Fibonacci.cpp in new project, and create new Class name as CUnitTester as below:

Step 3. Set the project properties as below:

  Additional including path: C:\project\gtest\include

  Additional library path: C:\project\gtest\lib

  Additional dependencies: gtest.lib gtest_main.lib

  Runtime Library: /MT

    *Special note: Runtime Library should be kept same as gtest.

  The testing project should link to specified release version or debug version Google Test libraries.

 

Step 4. Edit the UnitTester.h as below:

#include "Fibonacci.h"

#include

 

class CUnitTester:publictesting::Test

{

protected:

  CFibonacci * fib;

protected:

  virtual void SetUp()

  {

            fib= new CFibonacci();

  }

  virtual void TearDown()

  {

            delete fib;

  }

};

 

Step 5. Edit the UnitTester.cpp as below:

#include "StdAfx.h"

#include "UnitTester.h"

 

TEST_F(CUnitTester,Negative)

{

  EXPECT_EQ( 1, fib->GetFibonacci(-1) );

}

 

TEST_F(CUnitTester,TestForThree)

{

  EXPECT_EQ( 3, fib->GetFibonacci(3) );    

}

*The source code is described to use SetUp and TearDown, for easy purpose, below source codes is work fine also:

  1. Empty the UnitTester.h

  2. Edit UnitTester.cpp as below:

#include "Fibonacci.h"

#include

 

TEST(FibonacciTest,Negative)

{

    CFibonacci * fib = new CFibonacci();

    EXPECT_EQ( 1, fib->GetFibonacci(-1) );

    delete fib;

}

 

TEST(FibonacciTest,TestForThree)

{

    CFibonacci * fib = new CFibonacci();

    EXPECT_EQ( 3, fib->GetFibonacci(3) );

    delete fib;

}

 

Step 6. Build the testing project, and check the result:

 

 6.2 Google Test for Mac OS

  6.2.1 Install the Google Test

  Step 1. Download the Google Test from its download website:

     http://code.google.com/p/googletest/downloads/list

 

  Step 2. Open XCode project file in its xcode subfolder:

    

 

  Step 3. Set below three targets as Universal binary with Mac OS 10.4u SDK for release configuration.

                   

*That will be easy to use for most of our projects. Below is a sample setting:

 

      Step 4. Build out one framework and two static libraries.

           

        Copy gtest.framework to /Library/Frameworks, copy two static libraries to one specified folder, or /usr/local/lib in each SDK (All of them are placed in /Developer/SDKs).

 

  Now, Google Test is ready to use.

 

  6.2.2 Apply Google Test in your project

  One Fibonacci number program will be created to introduce application of Google Test. For implementation of Fibonacci number will be ignorred, we just create one command line tool and name source file and class as Fibonacci. Below steps is shown how to add Google Test base on this project.

  Step 1.   Add new “BSD - Shell Tool” target in the project , and name as Testing:

 

  Step 2. Create new group “UnitTest” in source tree, and add new C++ file and name as Testing.

    Assign these new file to be included in “Testing” target only as below:

   

  Step 3.  Drag below files into the project, and assign for Testing Target only.

      Drag Fibonacci.cpp to Testing target also. Finally, the Testing target should include below files:

           

  Step 4. Edit the Testing.h as below:

#include"Fibonacci.h"

#include

 

classFibTest :public testing::Test 

{

protected:

     Fibonacci * fib;

protected:

     virtual voidSetUp()

      {

                fib=new Fibonacci();

      }

     virtual voidTearDown()

      {

                delete fib;

      }

};

 

  Step 5. Edit Testing.cpp as below:

#include"Testing.h"

 

TEST_F(FibTest,Negative)

{

     EXPECT_EQ(1, fib->GetFibonacci(-1) );

}

 

TEST_F(FibTest,TestForThree)

{

     EXPECT_EQ(3, fib->GetFibonacci(3) );    

}

 

            intmain(intargc, char **argv)

            {

                    ::testing::InitGoogleTest(&argc, argv);

                    return RUN_ALL_TESTS();

}

 

If we won’t like to use these SetUp and TearDown functions, we could use below source codes:

a.    Clear Testing.h.

b.     Edit Testng.cpp as below:

 

#include"Fibonacci.h"

#include

 

TEST(FibonacciTest,Negative)

{

 Fibonacci * fib = new Fibonacci();

 EXPECT_EQ(1, fib->GetFibonacci(-1) );

 delete fib;

}

 

TEST(FibonacciTest,TestForThree)

{

 Fibonacci * fib = new Fibonacci();

 EXPECT_EQ(3, fib->GetFibonacci(3) );

 delete fib;

}

 

intmain(intargc, char **argv)

{

  ::testing::InitGoogleTest(&argc, argv);

 return RUN_ALL_TESTS();

}

 

        *If we won’t add main function by our own, perhaps below error will be happened:

This test program did NOT call ::testing::InitGoogleTest before calling RUN_ALL_TESTS().  Please fix it.

 

   Step 6. Run it and check the result.

      [==========] Running 2 tests from 1 test case.

[----------] Global test environment set-up.

[----------] 2 tests from FibonacciTest

[ RUN     ] FibonacciTest.Negative

[       OK ] FibonacciTest.Negative (0 ms)

[ RUN     ] FibonacciTest.TestForThree

[       OK ] FibonacciTest.TestForThree (0 ms)

[----------] 2 tests from FibonacciTest (0 ms total)

 

[----------] Global test environment tear-down

[==========] 2 tests from 1 test case ran. (0 ms total)

[  PASSED  ] 2 tests.

 

6.3 Supported Test Macros

Google Test allows use EXPECT_XX or ASSERT_XX for test macros.

Category

Macro

Description

Equality Tests

EXPECT_EQ(expected,actual)

Tests that expected == actual

EXPECT_NE(v1, v2)

Tests that v1 != v2

EXPECT_LT(v1, v2)

Tests that v1 < v2

EXPECT_LE(v1, v2)

Tests that v1 <= v2

EXPECT_GT(v1, v2)

Tests that v1 > v2

EXPECT_GE(v1, v2)

Tests that v1 >= v2

C String

EXPECT_STREQ(s1, s2)

Tests that s1 == s2

EXPECT_STRNE(s1, s2)

Tests that s1 != s2

EXPECT_STRCASEEQ(s1, s2)

Tests that s1 == s2, ignoring case

EXPECT_STRCASENE(s1, s2)

Tests that s1 != s2, ignoring case

Float & Double

EXPECT_FLOAT_EQ(expected,actual)

Tests that two float values are almost equal.

EXPECT_NEAR(v1,v2,abs_error)

Tests that v1 and v2 are within the given distance to each other.

EXPECT_DOUBLE_EQ(expected,actual)

Tests that two double values are almost equal.

Exception Tests

EXPECT_THROW(statement, expected_exception)

Tests that the statement throws the expected exception.

EXPECT_NO_THROW(statement)

Tests that the statement doesn't throw any exception.

EXPECT_ANY_THROW(statement)

Tests that the statement throws an exception.

Boolean

EXPECT_TRUE(condition)

Tests that the condition is true.

EXPECT_FALSE(condition)

Tests that the condition is false.

For more details, please refer to gtest/gtest.h.

 

7. CPPUnit

CPPUnit is a powerful unit testing framework for C/C++, and it could provide DLL testing mechnisam to support widely testing purpose. It also could support DDK environment, but the environment setup is more complex than other application.

 

Here, only CPPUnit for Windows DDK will be introduced.

 

 7.1 CPPUnit for Windows DDK

7.1.1 Install the CPPUnit

CPPUnit should be built with the specified WDK at first.

1. Setup the environment of Visual Studio for WDK

  A. Visual Studio -> Tools -> Options -> Projects and Solutions -> VC++ Directories. Show directories for:

    Include files

  . Add below list:

    C:\WinDDK\6801.0\inc\api

        C:\WinDDK\6801.0\inc\crt

        C:\WinDDK\6801.0\inc\ddk

        C:\WinDDK\6801.0\inc\api\crt\stl60

  B. Same setting UI.

    . Show directories for:

  Library files

  . Add below list:

    C:\WinDDK\6801.0\Lib\Crt\i386

        C:\WinDDK\6801.0\Lib\wnet\i386 <- For Windows 2003 only

 

  NOTE: Base on these settings, Visual Studio could build the WDK project also.

 

2. Open cppunit project and change below settings:

  Project Properties -> C/C++ -> Advanced ->Calling Convention should be "__stdcall(/Gz)"

    *Remember target application should have same "Calling Convention" setting.

  *WDK compiler set the "Calling Convention" to stdcall. (And I don't know how to change it)

 Project Properties -> C/C++ -> Code Generation -> Runtime Library should be "Multi-threaded (/MT)"

    *Note that different linking mode has different settings.

 

3. Build "cppunit" solutions in Release mode. (Debug mode is unnecessary.)

  *Remember to copy one to specified folder for WDK using only.

 

 7.1.2 Create new project in WDK.

1. Add below items in source files

 CPPUNITDIR=E:\project\cppunit  <- Constant definition

 TARGETNAME=UnitRunner <- Target application name

 TARGETPATH=obj

 TARGETTYPE=PROGRAM

 UMTYPE=console

 UMENTRY=main

 USE_LIBCMT = 1  <- To use standard runtime library for /MT. DO NOT USE MSVCRT, that is for /MD

 USE_IOSTREAM =1

 USE_STL=1  <- The cppunit is depended on STL library

 STL_VER=60 <- This version should keep same as cppunit. cppunit(VS2005) should set this item to 60.

 USE_NATIVE_EH=1

 MSC_OPTIMIZATION=/Od /Oi

 _NT_TARGET_VERSION = 0x0501 <-Define the target operation system. This is same as testing platform.

 C_DEFINES=$(C_DEFINES) /D_STL60_

 

2. Add include path of CPPUnit

 INCLUDES=$(DDK_INC_PATH);$(INCLUDES);$(CPPUNITDIR)\include;

 

3. Add cppunit library in LIB list:

 TARGETLIBS=$(TARGETLIBS) \

  ......

  $(CPPUNITDIR)\lib\WDK\cppunit.lib

 

  *Sometime, you may need other libraries, add them here.

 

4. Add source files in sources and start building.

Below are sample codes:

  main.cpp

#include BriefTestProgressListener.h>

#include

#include TestFactoryRegistry.h>

#include

#include h>

#include

extern "C"

{

int __cdecl main( int argc, char* argv[] )

{

  // Create the event manager and test controller

  CPPUNIT_NS::TestResult controller;

 

  // Add a listener that colllects test result

  CPPUNIT_NS::TestResultCollector result;

  controller.addListener( &result );      

 

  // Add a listener that print dots as test run.

  CPPUNIT_NS::BriefTestProgressListener progress;

  controller.addListener( &progress );    

 

  // Add the top suite to the test runner

  CPPUNIT_NS::TestRunner runner;

  runner.addTest( CPPUNIT_NS::TestFactoryRegistry::getRegistry().makeTest() );

  runner.run( controller );

 

  // Print test in a compiler compatible format.

  CPPUNIT_NS::CompilerOutputter outputter( &result, CPPUNIT_NS::stdCOut() );

  outputter.write();

 

  return result.wasSuccessful() ? 0 : 1;

}

}

 

      TestCase.h

                    #include HelperMacros.h>

                    class ScanAPITestSuite : public CPPUNIT_NS::TestFixture

{

  CPPUNIT_TEST_SUITE( ScanAPITestSuite );

  CPPUNIT_TEST( InitializeTesting );

  CPPUNIT_TEST_SUITE_END();

 

protected:

    CPMXScanAPI * m_pScanAPI;

public:

    ScanAPITestSuite();

public:

  void setUp();

  void tearDown();

 

protected:

  void InitializeTesting();

};

 

      TestCase.cpp

                    #include h>

#include "TestCase.h"

                    CPPUNIT_TEST_SUITE_REGISTRATION( ScanAPITestSuite );

 

/*!

@brief Description:

  Test case for initializing.

*/

void ScanAPITestSuite::InitializeTesting()

{

    HRESULT hr=S_OK;

    hr = CreatePMXScanner(&m_pScanAPI,KILO_WIA_PROJECT,TEXT("USBScan001"));

    CPPUNIT_ASSERT_MESSAGE("CreatePMXScanner won't be failed!", S_OK==hr);

   

    hr = m_pScanAPI->PMXScanner_Initialize();

    CPPUNIT_ASSERT_MESSAGE("PMXScanner_Initialize won't be failed!", S_OK==hr);

}

 

/*!

@brief Description:

  Test case for PMXScanner_GetTopPropertyInfo function.

*/

void ScanAPITestSuite::Check_GetTopPropertyInfo()

{

    PTOP_ITEM_INFORMATION pTopItem = new TOP_ITEM_INFORMATION;

   

    InitializeTesting();

   

    m_pScanAPI->PMXScanner_GetTopPropertyInfo(pTopItem);

   

    CPPUNIT_ASSERT(100 == pTopItem->Brightness.lMax);

    CPPUNIT_ASSERT(-100 == pTopItem->Brightness.lMin);

   

    CPPUNIT_ASSERT(100 == pTopItem->Contrast.lMax);

    CPPUNIT_ASSERT(-100 == pTopItem->Contrast.lMin);

   

    CPPUNIT_ASSERT(100 == pTopItem->Threshold.lMax);

    CPPUNIT_ASSERT(-100 == pTopItem->Threshold.lMin);

   

    CPPUNIT_ASSERT(600 == pTopItem->XResolution.lMax);

    CPPUNIT_ASSERT(75 == pTopItem->XResolution.lMin);

    CPPUNIT_ASSERT(150 == pTopItem->XResolution.lNom);

   

    CPPUNIT_ASSERT(600 == pTopItem->YResolution.lMax);

    CPPUNIT_ASSERT(75 == pTopItem->YResolution.lMin);

    CPPUNIT_ASSERT(150 == pTopItem->YResolution.lNom);

   

    delete pTopItem;

}

/* Below are helper functions*/

ScanAPITestSuite::ScanAPITestSuite()

{

    m_pScanAPI = NULL;

}

 

void ScanAPITestSuite::setUp()

{

    if(m_pScanAPI)

    {

                delete m_pScanAPI;

                m_pScanAPI = NULL;

    }

}

 

void ScanAPITestSuite::tearDown()

{

    if(m_pScanAPI)

    {

                delete m_pScanAPI;

                m_pScanAPI = NULL;

    }

}

*Note: The building target should same as testing platform. If you want run the unit testing on Win XP, you should define the target to Windows XP.

     

 7.2 Supported Test Macros

Macro

Description

CPPUNIT_ASSERT

Assertions that a condition is true.

CPPUNIT_ASSERT_MESSAGE

Assertion with a user specified message.

CPPUNIT_FAIL

Fails with the specified message.

CPPUNIT_ASSERT_EQUAL

Asserts that two values are equals.

CPPUNIT_ASSERT_EQUAL_MESSAGE

Asserts that two values are equals, provides additional messafe on failure.

CPPUNIT_ASSERT_DOUBLES_EQUAL

Macro for primitive value comparisons.

CPPUNIT_ASSERT_THROW

Asserts that the given expression throws an exception of the specified type.

CPPUNIT_ASSERT_NO_THROW

Asserts that the given expression does not throw any exceptions.

CPPUNIT_ASSERT_ASSERTION_FAIL

Asserts that an assertion fails.

CPPUNIT_ASSERT_ASSERTION_PASS

Asserts that an assertion passes.

 

8. OCUnit

OCUnit the standard Objective-C Unit Test framework for Mac OS and iOS development, that is extedned from SenTesting Framework which is written by Sen:Te. Due to it is bundled with XCode, developer could use it directly without any else installation.

 

8.1 Overview

OCUnit works in different way with other Unit Test framework, all suites and cases are runned after building, so all unexcepted result will be shown as compiling errors.

OCUnit is similar as Google Test without main function, it will be built as one bundle with .octest extention, and run with developer tools – RunUnitTests, which is placed in /Developer/Tools folder.

 

8.2 Sample to add unit test

Below is a sample code to generate Fibonacci numbers. There are three source files:

  Fibonacci.h, Fibonacci.m and main.m

 

The implementation of this project is ignored. Below steps are shown to add unit test base on this project.

 

Step 1. Create new group “UnitTest” in source tree, and add new source file as below:

 

Step 2. Name new class as Testing, and finish with wizard.

 

Step 3. Add below codes for Testing.h

#importh>

#import"Fibonacci.h"

 

@interfaceTesting : SenTestCase {

     

     Fibonacci * fib;

}

-(void)testNegative;

@end

 

Step 4. Add below codes for Testing.m

#import"Testing.h"

 

@implementationTesting

-(void)setUp

{

     fib = [[Fibonacci alloc]init];

}

 

-(void)tearDown

{

      [fib release];

}

 

-(void)testNegative

{

     STAssertTrue(1==[fib GetFibonacci:-1],@"For Negative, the result should be 0.");

}

@end

 

Step 5. Add new unit test bundle target.

Create new unit test bundle as below:

 

And drag Fibonacci.h, Fibonacci.m, Testing.h and Testing.m into this target as below:

 *And remove Testing.m from original target.  You also could create the target first, and then add new file for it only. That method was introduced in 6.2.

 

Step 6. Drag the new target into our own target to merge it with the project. Then the unit testing bundle will be built first while building the project.

Step 7. Try to build the project and check the message for failed case:

 

8.3 Supported Test Macros

Below is the table to list major supported test macros:

Category

Macro

Description

Equality Tests

STAssertEqualObjects

Fails the test case when two objects are different.

STAssertEquals

Fails the test case when two values are different.

STAssertEqualsWithAccuracy

Fails the test case when the difference between two values is greater than a given value.

Nil Tests

STAssertNil

Fails the test case when a given expression is not nil

STAssertNotNil

Fails the test case when a given expression is nil.

Boolean Tests

STAssertTrue

Fails the test case when a given expression is false.

STAssertFalse

Fails the test case when a given expression is true.

Exception Tests

STAssertThrows

Fails the test case when an expression doesn’t raise an exception.

STAssertThrowsSpecific

Fails the test case when an expression doesn’t raise an exception of a particular class.

STAssertThrowsSpecificNamed

Fails the test case when an expression doesn’t raise an exception of a particular class with a given name.

STAssertNoThrow

Fails the test case when an expression raises an exception.

STAssertNotThrowsSpecific

Fails the test case when an expression raises an exception of a particular class.

STAssertNotThrowsSpecificNamed

Fails the test case when an expression doesn’t raise an exception of a particular class with a given name.

STAssertTrueNoThrow

Fails the test case when an expression is false or raises an exception.

STAssertFalseNoThrow

Fails the test case when an expression is true or raises an exception.

 

 For more details, please refer to <> from Apple Developer Documentation.

 

9. Guideline to apply unit test

The major problem to apply unit test is how to balance it with general development. The benefit could not be turned up if unit test still be kept in discussion. That’s difficult to apply mutual Unit Test at first time. The unit test should be applied step by step, and implement regression test is a good start point.

 

Generally, there are two steps to think about one unit test case.

1.    The key point is identifying the core module, which should be low coupling with other modules.

2.    To identify the testing interface and all available testing conditions. (To find when it could not work.)

 

 

Below are correct situations to apply unit test:

9.1 While one bug is found (Core module)

Try to think about to add one test case to keep the correction, and remember to run the test case while building.

Think about below questions:

  Why this error happened?

  How to ensure similar errors won’t happen again?

  

9.2 While new design is requested

Try to think about involving unit test for your new design; though one simple testing suite will be designed.

At this point, it is a very good chance to think about to implement unit test. Think about below questions:

How many classes/objects or functions in the new design?

What major interface or functions for each of them?

How to ensure them won’t make mistake?

Which classes/objects or functions could be picked up for unit test?

What will you get from unit test?

 

10. Reference

  1. 便利的开发工具 CppUnit 快速使用指南

      http://www.ibm.com/developerworks/cn/linux/l-cppunit/

 

   2.Test Driving Your Code with OCUnit


 

   3.玩转Google开源C++单元测试框架Google Test系列

     http://www.cnblogs.com/coderzh/archive/2009/04/06/1426755.html

 

  4. 单元测试之JUnit秘籍专题


 5.玩转Google开源C++单元测试框架 http://www.cnitblog.com/zouzheng/archive/2009/09/28/61614.html
 

目录
相关文章
|
3月前
|
敏捷开发 测试技术 持续交付
探索自动化测试在敏捷开发中的应用与挑战
本文深入探讨了自动化测试在现代软件开发流程,特别是敏捷开发环境中的重要作用和面临的挑战。通过分析自动化测试的基本原理、实施策略以及在实际项目中的应用案例,揭示了其在提高软件质量和加速产品交付方面的巨大潜力。同时,文章也指出了自动化测试实施过程中可能遇到的技术难题、成本考量及团队协作问题,并提出了相应的解决策略,为软件开发团队提供了有价值的参考和指导。
|
2月前
|
Java 测试技术 数据安全/隐私保护
软件测试中的自动化策略与工具应用
在软件开发的快速迭代中,自动化测试以其高效、稳定的特点成为了质量保证的重要手段。本文将深入探讨自动化测试的核心概念、常见工具的应用,以及如何设计有效的自动化测试策略,旨在为读者提供一套完整的自动化测试解决方案,帮助团队提升测试效率和软件质量。
|
3月前
|
编解码 测试技术 开发工具
测试 iPhone 应用在不同屏幕尺寸和分辨率下的响应式效果
【10月更文挑战第23天】测试 iPhone 应用在不同屏幕尺寸和分辨率下的响应式效果是确保应用质量和用户体验的重要环节。通过手动测试、自动化测试、视觉效果评估、性能测试、用户体验测试等多种方法的综合运用,能够全面地发现应用在响应式效果方面存在的问题,并及时进行解决和优化。同时,持续的测试和优化也是不断提升应用质量和用户满意度的关键。
|
23天前
|
搜索推荐 测试技术 API
探秘电商API:从测试到应用的深度解析与实战指南
电商API是电子商务背后的隐形引擎,支撑着从商品搜索、购物车更新到支付处理等各个环节的顺畅运行。它通过定义良好的接口,实现不同系统间的数据交互与功能集成,确保订单、库存和物流等信息的实时同步。RESTful、GraphQL和WebSocket等类型的API各自适用于不同的应用场景,满足多样化的需求。在测试方面,使用Postman、SoapUI和jMeter等工具进行全面的功能、性能和安全测试,确保API的稳定性和可靠性。未来,随着人工智能、大数据和物联网技术的发展,电商API将进一步智能化和标准化,为用户提供更个性化的购物体验,并推动电商行业的持续创新与进步。
55 4
|
3月前
|
监控 安全 测试技术
如何在实际项目中应用Python Web开发的安全测试知识?
如何在实际项目中应用Python Web开发的安全测试知识?
118 61
|
3月前
|
jenkins 测试技术 持续交付
探索自动化测试在持续集成中的应用与挑战
本文深入探讨了自动化测试在现代软件开发流程,特别是持续集成(CI)环境中的关键作用。通过分析自动化测试的优势、实施策略以及面临的主要挑战,旨在为开发团队提供实用的指导和建议。文章不仅概述了自动化测试的基本原理和最佳实践,还详细讨论了如何克服实施过程中遇到的技术难题和管理障碍,以实现更高效、更可靠的软件交付。
|
3月前
|
机器学习/深度学习 人工智能 测试技术
探索自动化测试框架在软件开发中的应用与挑战##
本文将深入探讨自动化测试框架在现代软件开发过程中的应用,分析其优势与面临的挑战。通过具体案例分析,揭示如何有效整合自动化测试以提升软件质量和开发效率。 ##
|
3月前
|
并行计算 算法 测试技术
C语言因高效灵活被广泛应用于软件开发。本文探讨了优化C语言程序性能的策略,涵盖算法优化、代码结构优化、内存管理优化、编译器优化、数据结构优化、并行计算优化及性能测试与分析七个方面
C语言因高效灵活被广泛应用于软件开发。本文探讨了优化C语言程序性能的策略,涵盖算法优化、代码结构优化、内存管理优化、编译器优化、数据结构优化、并行计算优化及性能测试与分析七个方面,旨在通过综合策略提升程序性能,满足实际需求。
99 1
|
3月前
|
敏捷开发 监控 jenkins
探索自动化测试框架在敏捷开发中的应用与优化##
本文深入探讨了自动化测试框架在现代敏捷软件开发流程中的关键作用,分析了其面临的挑战及优化策略。通过对比传统测试方法,阐述了自动化测试如何加速软件迭代周期,提升产品质量,并针对实施过程中的常见问题提出了解决方案。旨在为读者提供一套高效、可扩展的自动化测试实践指南。 ##
63 9
|
3月前
|
监控 JavaScript 前端开发
如何在实际应用中测试和比较React和Vue的性能?
总之,通过多种方法的综合运用,可以相对客观地比较 React 和 Vue 在实际应用中的性能表现,为项目的选择和优化提供有力的依据。
64 1

热门文章

最新文章