Libzypp/WritingTests

From openSUSE

Good testing allows any piece of software to be more robust and predictable. Indirectly, testing improves the design of software because when it is designed with testing in mind, you have to take special care of decoupling components and isolate them, otherwise, it will be really hard to test it.

Let's see how ZYpp handles testing:

Core classes tests

Core classes are done using boost::test plus some conventions.

• One test program per class, functionality or component.
• group tests per subsystem or even per class, in directories.
• put test data into a data directory where the test resides, and make a directory for the test inside data.
• It is no problem for tests to use data from other tests. You will need it, for example, YUM sample repositories.

Here is the sample code of a test case:

#include <iostream>
#include <fstream>
#include <list>
#include <string>

#include <boost/test/unit_test.hpp>
#include <boost/test/parameterized_test.hpp>
#include <boost/test/unit_test_log.hpp>

using boost::unit_test::test_suite;
using boost::unit_test::test_case;
using namespace boost::unit_test::log;

using namespace std;
using namespace zypp;
using namespace zypp::filesystem;

void some_test( const string &dir )
{
    //BOOST_CHECK_EQUAL( object.size(), 3 ); 
}
  
test_suite*
init_unit_test_suite( int argc, char* argv[] )
{
  string datadir;
  if (argc < 2)
  {
    datadir = TESTS_SRC_DIR;
    datadir = (Pathname(datadir) + "/zypp/data/Classname").asString();
    cout << "classname_test:"
      " path to directory with test data required as parameter. Using " << datadir  << endl;
    //return (test_suite *)0;
  }
  else
  {
    datadir = argv[1];
  }

  std::string const params[] = { datadir };
    //set_log_stream( std::cout );
  test_suite* test= BOOST_TEST_SUITE( "ClassnameTest" );
  test->add(BOOST_PARAM_TEST_CASE( &some_test,
                              (std::string const*)params, params+1));
  return test;
}

The the init_unt_test_suite function has to create a unit test suite adding one or more tests. The tests are simple functions.

In these function you can perform tests. See the testing facilities of boost to see what is available.

You can notice we have taken special care to allow the test to have the data directory supplied as an argument (passed via the build system during make check) and to be able to use a default directory, useful when the test is run from command line. The TESTS_SRC_DIR macro is defined in this case.

You can add a test to the build system listing it in the CMakeLists.txt file in the same directory:

ADD_EXECUTABLE( MediaSetAccess MediaSetAccessTest.cc )
TARGET_LINK_LIBRARIES( MediaSetAccess zypp boost_unit_test_framework )
ADD_TEST(MediaSetAccessTest ${CMAKE_CURRENT_BINARY_DIR}/MediaSetAccess ${CMAKE_CURRENT_SOURCE_DIR}/data/mediasetaccess)

The first two lines are the same used when creating an executable. The last line, creates a test of the 1st argument name, using the 2nd argument binary, with the 3rd argument passed to the test binary (in this case the data dir).

Solver testcases

Solver testcases are generated combining one or more channels in the Helix format. A channel in helix format declares one or more packages, patches and other resolvables.

The channels are combined so one of them acts as "system" channel (installed resolvables) and the other ones are available as installation repositories.

The third part of the test defines the action to be done, and the later, a result file. All of this individual descriptions are referenced from a testcase file.

You can see some examples here.

• Creating solver testcases from YaST