Changes between Version 37 and Version 38 of GSoC/2014/TestingFrameworkForGRASS


Ignore:
Timestamp:
Jun 13, 2014, 7:59:06 PM (10 years ago)
Author:
wenzeslaus
Comment:

Weekly report 4

Legend:

Unmodified
Added
Removed
Modified

  • GSoC/2014/TestingFrameworkForGRASS

    v37 v38  
    5315311. What did you get done this week?
    532532
    533 The plan was to test unittest and doctest methods for evaluation and comparison of textual and numerical outputs (results) on GRASS use cases. The simple cases are solved by unittest. Besides the code I put to sandbox I wrote some tests of some functionality related to g.list [1], g.mlist and g.mremove.
     533The plan was to test unittest and doctest methods for evaluation and comparison of textual and numerical outputs (results) on GRASS use cases. The simple cases are solved by unittest. Besides the code I put to sandbox I wrote some tests of some functionality related to [source:grass/trunk/general/g.list/test_g_list.py?rev=60619 g.list], g.mlist and g.mremove.
    534534
    535535I discovered several functions in grass.script.core which can be used to solve more complex outputs of modules. So, I copied them, generalized them and wrote a tests for them (more work is needed). These functions can be used later to write tests but also in GRASS itself.
    536 Regarding the issue with testing using different languages (translations). With the tests I wrote [2] is seems that the best solution will be to use regular expressions or just Python `in` operator to test if the message contains the required information. In other words, test should be independent on language environment.
    537 
    538 I also explored the the possibility of using code coverage to evaluate the tests. It seems that with Python coverage package [4], we can get code coverage (reports) for Python library without much burden at least for basic cases (no modules involved, no ctypes).
     536Regarding the issue with testing using different languages (translations). With the tests I wrote (especially the one for [http://trac.osgeo.org/grass/attachment/ticket/2228/test_g_mremove.py g.mremove]), it seems that the best solution will be to use regular expressions or just Python `in` operator to test if the message contains the required information. In other words, test should be independent on language environment.
     537
     538I also explored the the possibility of using code coverage to evaluate the tests. It [http://trac.osgeo.org/grass/changeset/60730 seems] that with Python [https://pypi.python.org/pypi/coverage coverage] package, we can get code coverage (reports) for Python library without much burden at least for basic cases (no modules involved, no ctypes).
    539539
    5405402. What do you plan on doing next week?
    … …  
    546546The fact that I also have to create the some tests to test the framework on some real world example slows me down but on the other hand, it is necessary and even very useful because I'm also testing things, such as the functions which will be used for creating the tests. And I discovered some problems right away.
    547547
    548 Vaclav
    549 
    550 [1] http://trac.osgeo.org/grass/browser/grass/trunk/general/g.list/test_g_list.py?rev=60619
    551 [2] http://trac.osgeo.org/grass/attachment/ticket/2228/test_g_mremove.py
    552 [3] http://trac.osgeo.org/grass/changeset/60730
    553 [4] https://pypi.python.org/pypi/coverage
    554 
    555 http://trac.osgeo.org/grass/browser/sandbox/wenzeslaus/gunittest?rev=60733
     548[http://lists.osgeo.org/pipermail/grass-dev/2014-June/069376.html report email], [source:browser/sandbox/wenzeslaus/gunittest?rev=60733 source state]
     549
     550=== Week 04 ===
     551
     5521. What did you get done this week?
     553
     554This week I was not able to work on GSoC as I planed because I needed to focus on other things, some of them GRASS-related. Most importantly, I was working on the GRASS FOSS4G workshop. Specifically, I was working on the format and technology to show examples and procedures in different languages (I'm not yet ready to publish the examples). In the relation to GSoC, I hope that the format I've designed will enable creation of tests based on materials like this which was one of my ideas for the alternative use cases for testing framework. By chance I also found a code quality evaluation tool, [https://github.com/GreenSteam/pep257 pep257], which is similar to pep8 but checks the [http://legacy.python.org/dev/peps/pep-0257/ style of docstrings].
     555
     5562. What do you plan on doing next week?
     557
     558I will try to make advances in comparison of raster and vector maps. There are different alternatives how maps can be compared ranging from check sums of raster map's files to text-based comparison of exports of vector maps.
     559
     560The plan for week five was rewriting some of the existing tests to the new format. But I already have some tests created in previous weeks and I'm writing tests for the framework itself, so I have enough material to work with.
     561
     5623. Are you blocked on anything?
     563
     564My weekly plan got delayed but I hope to catch up the schedule in the next two weeks.
     565
     566[http://lists.osgeo.org/pipermail/grass-dev/2014-June/069504.html report email]