[gdal-dev] GDAL testing

[Mateusz Loskot]

Hi Kurt,

I'm interested in this topic, so I'd like to pull some more details to
better
understand the idea, if you don't mind.


Kurt Schwehr-2 wrote
> For my production work, I'm not able to use the autotest python code
> because of its non-unittest architecture.

Could you elaborate more on what properties exactly are missing
from the current autotest suite?
IOW, what kind of gap autotest2 fills.

Yes, autotest is not a unit testing suite.
To me, it combines functional/integration/blackbox/system/regression
testing.


Kurt Schwehr-2 wrote
> So... I started creating python
> unittest and C++ gunit based tests. 

Since you mention unittest, then gmock too?


Kurt Schwehr-2 wrote
> The tests are more focused on test isolation than autotest.  This allows
> for a lot more parallelism in testing.

Isolation at what level?
I suppose, you mean test case isolation, but not isolation of code/unit
under test.

So, the former means each test case runs in isolated environment,
with exclusive access to files/databases/memory/resources required by
particular test.
For example, each run of ogr_mysql.py, also in parallel, exclusively targets
a 'unique' database.

Correct?


Kurt Schwehr-2 wrote
> Here are some samples:
> 
> C++ tests use  C++11, gunit, google logging, gflags:  (Hoping for C++14
> soon.. e.g. make_unique)
> - autotest2/cpp/port/cpl_conv_test.cc
> <https://gist.github.com/schwehr/13137d826763763fb031> (Yes, this is
> massively boring code)

AFAIS, architecture of tests won't change much, typically, test cases will
target functional modules (drivers).
Or, do you plan for proper unit tests targeting individual
interfaces/classes
in internal implementation of drivers, etc.?


Kurt Schwehr-2 wrote
> I'm (mostly) following Google's style guides.
> All C++ should be formatted with "clang-format --style=Google"

Unless it is not planned to include autotest2 into GDAL source code,
shouldn't it follow GDAL style?


Kurt Schwehr-2 wrote
> Would like to eventually do (unsorted):
> - Fuzz testing, ASAN/MSAN/TSAN/Valgrind/Heap checks  (I've done some MSAN
> &
> heap checkers by hand)
> - Performance testing - time and memory usage

IMHO, those belong to separate suites.


- Test the C API at the C level
</qoute>

If plain unittests are planned, mocking might be possible.

Best regards,
Mateusz



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GDAL-testing-tp5222783p5230596.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.