Tag Archives: testing

mloskot @ boost regression tests

Posted on by
Reply

I run Boost C++ Libraries regression tests for the first time today. The test driver is brilliant. It’s a single python script run.py that takes care of all aspects of regression tests run: gets build system, builds bjam (a clever make equivalent) if not available, grabs Boost source tree, builds Boost libraries, runs tests, combines tests reports to single XML files and uploads it to server in secret location. All this by single command:

python run.py --tag="trunk" --runner="mloskot-x86_64" \
   --toolsets="gcc" --bjam-toolset="gcc" --bjam-options="-j4"

Then, a scheduled magic on the server crunches all uploaded reports and builds detailed summary of regression tests. My builder is called mloskot-x86_64.

That is really a user friendly infrastructure of running regression tests and it allows an average Boost user to contribute in testing.

Testing libLAS with CMake

Posted on by
Reply

libLAS - ASPRS LiDAR data translation toolset As a part of CMake configuration for libLAS, I’ve enabled support CTest. It is CMake test driver program that can be used to run automated tests and perform continuous integration. I also registered libLAS at CDash testing server.

CDash aggregates, analyzes and displays the results of software testing processes submitted from clients located around the world

Check libLAS dedicated quality dashboard – registration is required it is public project and available for anonymous visitors to browse the dashboard (thanks to Julien from Kitware for quick fix).

Anyone who is would like to build libLAS using CMake and run tests can find details on the CMake article on the Wiki. I would also encourage interested users to issue make Continuous to submit test results to the dashboard.

Feedback kindly wanted!

Compile-time unit tests

Posted on by
Reply

Boost Build V2 includes testing module that provides nice features for running unit tests. A unit test run means a test builds and can be executed performing checks in run-time, however, a unit test can be also based on compilation or even linking result. Yet more surprisingly, sometimes a test is expected to not to compile and such failure is considered as success. It performs compile-time checking in design by contract.

In Generic Geometry Library, some tests use that feature of testing compilation result. For example, this way it’s possible to test the concepts in practice and to ensure that various constructs are not accepted by the library as expected by design.

For example, custom_linestring.cpp source file can be used to perform compile-time and run-time testing. If TEST_FAIL_APPEND is defined, unacceptable constructs are compiled and the compilation is expected to fail. If compiled without TEST_FAIL_APPEND defined, only acceptable code is enabled and regular run-time test performed.

Configuration of such thing is very easy with Boost Build V2. Here is Jamfile.v2 that performs the test for geometries in Generic Geometry Library using compile-fail rule:

test-suite ggl-geometries
    :
    [ compile-fail custom_linestring.cpp
        : # requirements
        <define>TEST_FAIL_APPEND
        : # target name
        custom_linestring_test_fail_append
    ]
    [ run custom_linestring.cpp ]

There are among others also rules like compile, link-fail and link.

The unit tests execution is simple:

mloskot@dog:~/dev/ggl/_svn/trunk/libs/ggl/test/geometries$ bjam | grep passed
**passed** bin/custom_linestring_test_fail_append.test/gcc-4.4.1/debug/custom_linestring_test_fail_append.test
**passed** bin/custom_linestring.test/gcc-4.4.1/debug/custom_linestring.test

Run WKT Raster, run!

Posted on by
4

I have a not-so-small GeoTIFF raster dataset. Here is what GDAL has to say about it:

$ gdalinfo japan.tif
Driver: GTiff/GeoTIFF
Files: japan.tif
Size is 14000, 14000
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.2572235630016,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (137.386330630776030,38.325757833006122)
Pixel Size = (0.000256020461176,-0.000256020461176)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_DOCUMENTNAME=ER Mapper 6.4
  TIFFTAG_IMAGEDESCRIPTION=ER Mapper GeoTiff raster translator V1.0: Band 1 = Red, Band 2 = Green, Band 3 = Blue
  TIFFTAG_SOFTWARE=ER Mapper 6.4
  TIFFTAG_XRESOLUTION=0
  TIFFTAG_YRESOLUTION=0
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  ( 137.3863306,  38.3257578) (137d23'10.79"E, 38d19'32.73"N)
Lower Left  ( 137.3863306,  34.7414714) (137d23'10.79"E, 34d44'29.30"N)
Upper Right ( 140.9706171,  38.3257578) (140d58'14.22"E, 38d19'32.73"N)
Lower Right ( 140.9706171,  34.7414714) (140d58'14.22"E, 34d44'29.30"N)
Center      ( 139.1784739,  36.5336146) (139d10'42.51"E, 36d32'1.01"N)
Band 1 Block=14000x20 Type=Byte, ColorInterp=Red
Band 2 Block=14000x20 Type=Byte, ColorInterp=Green
Band 3 Block=14000x20 Type=Byte, ColorInterp=Blue

I loaded it to PostGIS/WKT Raster table with regular blocking enabled in PostgreSQL 8.3 database running on Ubuntu 8.10 (32-bit) installed as a guest system under VirtualBox:

$ gdal2wktraster.py -r japan.tif -t japan_rb -o japan_rb.sql -k
$ psql -d test -f japan_rb.sql

The loader generated output file japan_rb.sql of size of 1.1 GB and it makes 700 records (raster tiles or blocks) in the database. The disk usage reported for the raster table is:

sistest=# SELECT relfilenode, relpages FROM pg_class WHERE relname = 'japan_rb';
 relfilenode | relpages
-------------+----------
       71700 |        5
(1 row)

I run simple test query:

$ psql -d test
test=# SET log_statement_stats TO 1;
SET
test=# SELECT rid FROM japan_rb WHERE RT_Width(rast) != 14000 OR RT_Height(rast) != 20;
 rid
-----
(0 rows)

In the PostgreSQL log I got dumped a bunch of interesting statistics:

2009-03-27 15:23:38 GMT LOG:  QUERY STATISTICS
2009-03-27 15:23:38 GMT DETAIL:  ! system usage stats:
 ! 5.084838 elapsed 2.544159 user 2.468154 system sec
 ! [4.960310 user 5.204325 sys total]
 ! 0/0 [16/28160] filesystem blocks in/out
 ! 0/320190 [0/647479] page faults/reclaims, 0 [0] swaps
 ! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
 ! 0/155 [9/327] voluntary/involuntary context switches
 ! buffer usage stats:
 ! Shared blocks:      74192 read,          0 written, buffer hit rate = 51.71%
 ! Local  blocks:          0 read,          0 written, buffer hit rate = 0.00%
 ! Direct blocks:          0 read,          0 written

The virtual machine has assigned 1024 MB of RAM and one CPU Intel Xeon 3.2 GHz.

You are strongly welcome to share your comments?