<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 05-10-16 15:20, Moritz Lennert
      wrote:<br>
    </div>
    <blockquote
      cite="mid:fddbe68b-1b7e-95ac-8a7e-7317a59a075a@club.worldonline.be"
      type="cite">On 05/10/16 14:24, Sören Gebbert wrote:
      <br>
      <blockquote type="cite">Hi,
        <br>
        <br>
        2016-10-05 10:20 GMT+02:00 Moritz Lennert
        <<a class="moz-txt-link-abbreviated" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>
        <br>
        <a class="moz-txt-link-rfc2396E" href="mailto:mlennert@club.worldonline.be"><mailto:mlennert@club.worldonline.be></a>>:
        <br>
        <br>
            [sent this from the wrong address, so it didn't get through
        to the list]
        <br>
        <br>
        <br>
            -------- Message d'origine --------
        <br>
            Envoyé : 5 octobre 2016 00:41:20 GMT+02:00
        <br>
        <br>
        <br>
        <br>
            Le 4 octobre 2016 22:55:35 GMT+02:00, "Anna Petrášová"
        <br>
            <<a class="moz-txt-link-abbreviated" href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>
        <a class="moz-txt-link-rfc2396E" href="mailto:kratochanna@gmail.com"><mailto:kratochanna@gmail.com></a>> a écrit :
        <br>
            >On Tue, Oct 4, 2016 at 4:22 PM, Markus Metz
        <br>
            ><<a class="moz-txt-link-abbreviated" href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>
        <br>
            <a class="moz-txt-link-rfc2396E" href="mailto:markus.metz.giswork@gmail.com"><mailto:markus.metz.giswork@gmail.com></a>> wrote:
        <br>
            >> On Tue, Oct 4, 2016 at 5:42 PM, Sören Gebbert
        <br>
            >> <<a class="moz-txt-link-abbreviated" href="mailto:soerengebbert@googlemail.com">soerengebbert@googlemail.com</a>
        <br>
            <a class="moz-txt-link-rfc2396E" href="mailto:soerengebbert@googlemail.com"><mailto:soerengebbert@googlemail.com></a>> wrote:
        <br>
            >>> Hi,
        <br>
            >>>>
        <br>
            >>>>
        <br>
            >>>> >
        <br>
            >>>> > You are very welcome to write the
        missing tests for core modules.
        <br>
            >>>> >
        <br>
            >>>> > However, i don't understand the
        argument that because many core
        <br>
            >modules
        <br>
            >>>> > have
        <br>
            >>>> > no tests, therefore new modules don't
        need them. If developers of
        <br>
            >addon
        <br>
            >>>> > module are serious about the attempt
        to make their modules usable
        <br>
            >and
        <br>
            >>>> > maintainable for others, then they
        have to implement tests. Its
        <br>
            >and
        <br>
            >>>> > integral
        <br>
            >>>> > part of the development process and
        GRASS has a beautiful test
        <br>
            >>>> > environment
        <br>
            >>>> > hat makes writing tests easy. Tests
        and documentation are part of
        <br>
            >coding
        <br>
            >>>> > and
        <br>
            >>>> > not something special. I don't think
        this is a hard requirement.
        <br>
            >>>> >
        <br>
            >>>> > There is a nice statement that is not
        far from the truth:
        <br>
            >Untested code
        <br>
            >>>> > is
        <br>
            >>>> > broken code.
        <br>
            >>>>
        <br>
            >>>> these gunittests only test if a module
        output stays the same. This
        <br>
            >>>
        <br>
            >>>
        <br>
            >>> This is simply wrong, please read the gunittest
        documentation.
        <br>
            >>
        <br>
            >> but then why does
        <br>
            >>>
        <br>
            >>> The gunittest for the v.stream.order addon is
        an example how its
        <br>
            >done:
        <br>
            >>>
        <br>
           
><a class="moz-txt-link-freetext" href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py">https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py</a><br>
           
<a class="moz-txt-link-rfc2396E" href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py"><https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py></a><br>
            >>
        <br>
            >> assume certain order numbers for features 4 and 7?
        What if these
        <br>
            >order
        <br>
            >> numbers are wrong?
        <br>
            >>
        <br>
            >> Recently I fixed bugs in r.stream.order, related to
        stream length
        <br>
            >> calculations which are in turn used to determine
        stream orders. The
        <br>
            >> gunittest did not pick up 1) the bugs, 2) the bug
        fixes.
        <br>
            >>
        <br>
            >>>
        <br>
            >>> You can write gunittests that will test every
        flag, every option,
        <br>
            >their
        <br>
            >>> combination and any output of a module. I have
        implemented plenty of
        <br>
            >tests,
        <br>
            >>> that check for correct error handling. Writing
        tests is effort, but
        <br>
            >you have
        <br>
            >>> to do it anyway. Why not implementing a
        gunittest for every feature
        <br>
            >while
        <br>
            >>> developing the module?
        <br>
            >>>>
        <br>
            >>>>
        <br>
            >>>> My guess for the r.stream.* modules is at
        least 40 man hours of
        <br>
            >>>> testing to make sure they work correctly.
        That includes evaluation
        <br>
            >of
        <br>
            >>>> float usage, handling of NULL data,
        comparison of results with and
        <br>
            >>>> without the -m flag. Testing should be done
        with both high-res
        <br>
            >(LIDAR)
        <br>
            >>>> and low-res (e.g. SRTM) DEMs.
        <br>
            >>>
        <br>
            >>>
        <br>
            >>> Tests can be performed on artificial data that
        tests all aspects of
        <br>
            >the
        <br>
            >>> algorithm. Tests that show the correctness of
        the algorithm for
        <br>
            >specific
        <br>
            >>> small cases should be preferred. However, large
        data should not be
        <br>
            >an
        <br>
            >>> obstacle to write a test.
        <br>
            >>
        <br>
            >> I agree, for tests during development, not for
        gunittests.
        <br>
            >>
        <br>
            >> From the examples I read, gunittests expect a
        specific output. If the
        <br>
            >> expected output (obtained with an assumed correct
        version of the
        <br>
            >> module) is wrong, the gunittest is bogus.
        gunittests are ok to make
        <br>
            >> sure the output does not change, but not ok to make
        sure the output
        <br>
            >is
        <br>
            >> correct. Two random examples are r.stream.order and
        r.univar.
        <br>
            >
        <br>
            >
        <br>
            >I am not sure why are we discussing this, it's pretty
        obvious that
        <br>
            >gunittests can serve to a) test inputs/outputs b) catch
        changes in
        <br>
            >results (whether correct or incorrect) c) test
        correctness of results.
        <br>
            >It just depends how you write them, and yes, for some
        modules c) is
        <br>
            >more difficult to implement than for others.
        <br>
        <br>
        <br>
            Well, I agree with Markus that unittests are not a panacea
        and that
        <br>
            we should not fall into the trap of thinking that these
        tests will
        <br>
            guarantee that the results of our modules are correct.
        <br>
        <br>
        <br>
        Then i live in a parallel universe. Simple question: How do you
        test
        <br>
        your software? How do you assure the correct functionality of
        your
        <br>
        software? Why is it impossible to implement your approach of
        testing in
        <br>
        a dedicated gunittest? How do you assure software quality, if
        you don't
        <br>
        provide tools so that other developers are able to test your
        software
        <br>
        for correctness? Regression tests are not possible then, because
        the
        <br>
        effect of changes in the core libraries can not be easily
        detected in
        <br>
        modules without tests.
        <br>
      </blockquote>
      <br>
      <br>
      Please note that I was speaking about unit tests, here. I don't
      know how efficient our testing framework is for integration
      testing ? Maybe we also need to be clearer about what we
      understand by tests during such discussions ?
      <br>
      <br>
      Good discussion, though ! :-)
      <br>
      <br>
      <blockquote type="cite">
        <br>
        Can you explain to me why the developers of the sophisticated
        software
        <br>
        system VTK [1] implement unit and integration tests for all
        software
        <br>
        components to assure the correct functionality of the framework?
        They
        <br>
        didn't saw the trap? They are delusional to think that tests
        assure
        <br>
        software quality?
        <br>
        <br>
        Why is test driven development [2] an integral part of agile
        software
        <br>
        development approaches like scrum or extreme programming? They
        didn't
        <br>
        saw the trap? They are delusional to think that tests assure
        software
        <br>
        quality?
        <br>
        <br>
        [1] <a class="moz-txt-link-freetext" href="http://www.vtk.org/overview/">http://www.vtk.org/overview/</a>
        <br>
        [2] <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Test-driven_development">https://en.wikipedia.org/wiki/Test-driven_development</a>
        <br>
        <br>
        <br>
            However, I do agree that these tests are useful in detecting
        if any
        <br>
            changes to the code change the output, thus raising a flag
        that the
        <br>
            developer has to at least take into account.
        <br>
        <br>
            I'll try to write some tests for the OBIA tools when I find
        the
        <br>
            time, although I do agree with Markus that it wouldn't be
        useful to
        <br>
            try to write tests that would cover each and every possible
        corner
        <br>
            case...
        <br>
        <br>
        <br>
        Why is it "not useful" to write tests for all cases the software
        is
        <br>
        dedicated to solve? It is indeed a lot of effort, but it is
        useful.
        <br>
      </blockquote>
      <br>
      I would say the question is rather, first, whether it is at all
      possible, and, second, that maybe by thinking that it is, we are
      too confident in our tests providing information that they really
      aren't trying to provide.
      <br>
      <br>
      But I'm no expert whatsoever, on the topic (I am not a computer
      scientist, just a scientist programming some tools with my very
      limited capabilities), so I don't want to stretch this discussion
      out. I do recommend reading this, though:
      <br>
<a class="moz-txt-link-freetext" href="http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf">http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf</a>
      <br>
      <br>
      I also like the table close to the top of
      <br>
      <br>
<a class="moz-txt-link-freetext" href="http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/">http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/</a>
      <br>
      <br>
      (attached as image)
      <br>
      <br>
      And let's remember that this all started as the question of what
      should be required for a module to move from addons to core. The
      question, therefore, is to find the right balance between
      necessary effort and our desire to offer functionality to users.
      This also raises the question of why it would be better for a
      given module to be in core, rather than in extensions. We could
      also imagine the opposite direction, i.e. move modules from core
      to extensions to lighten the work load of maintaining core, while
      still offering the same functionalities.
      <br>
      <br>
      IMHO, the largest advantage of having a module in core is that
      when someone changes internal library APIs, then generally they
      check all of core and modify what needs to, but this is not
      necessarily the case for extensions...
      <br>
      <br>
      Maybe we should ask the users of whether this distinction between
      modules and core and extensions is really relevant for them, or
      whether most are perfectly happy to just install extensions.
      <br>
    </blockquote>
    <br>
    Since you are asking :-) , as an user, my main interest is in good
    documentation and reproducible examples (which I can than also use
    to see if outputs make sense to me as an user). In that respect
    there is no inherent difference between core modules and extensions.
    What is different is that many (most?) of the core functions are
    accessible through the menu. I personally don't find that very
    important, especially with the modules tab giving fairly easy access
    to extensions, but I can imagine that for new / other users,
    especially those more inclined to menu-driven applications, this may
    make a difference.  <br>
    <br>
    <blockquote
      cite="mid:fddbe68b-1b7e-95ac-8a7e-7317a59a075a@club.worldonline.be"
      type="cite">
      <br>
      Moritz
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
grass-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>