Changes between Version 9 and Version 10 of GSoC/2014/TestingFrameworkForGRASS

Timestamp:

05/23/14 15:01:22 (11 years ago)

Author:

wenzeslaus

Comment:

about maps in location

GSoC/2014/TestingFrameworkForGRASS

@@ -212 +212 @@
 Tests (suites, cases, or scripts/modules) itself can define in which location or locations they should be executed as a global variable (both for unit and doctests, doctests in they their unittest wrapper). The global variable will be ignored in case the test script is executed by hand. When executed by make system, the test can be executed in all locations specified by the global variable, or one location specified by make system (or generally forced from the top). In other words, the global variable specifies what the test want to do, not what it is capable to do because we want it to run in any location.
 
+We should have dedicated test locations with different projections and identical map names. I wouldn't use the GRASS sample locations (NC, Spearfish) as test locations directly. We should have dedicated test locations with selected data (they can overlap with let's say NC but may contain less imagery but some additional strange data). The only difference between the locations would be the projection, so it really makes difference only for projected, latlon and perhaps XY.
+
 If multiple locations are allowed and we expect some maps being in the location such as elevation raster, it is not clear how to actually test the result such as aspect computed from elevation since the result (such as MD5 sum) will be different for each location/projection. This would mean that the checking/assert functions or tests themselves would have to handle different locations and moreover, this type of tests would always fail in the user provided location.
 
@@ -224 +226 @@
 Testing framework can have a function to check/test the current location (currently accessible mapsets) whether it contains all the required maps (according to their name).
 
-All reference files and additional data will be located in the `testsuite` directory.
+All reference files (and perhaps also additional data) will be located in the `testsuite` directory. There can be also one global directory with additional data (e.g. data to import) which will be shared between test suites and exposed by the testing framework.
 
 Testing framework design should allow us to make different decisions about how to solve data and locations questions.