test infrastructure ideas appreciated ... -- automatically generated unit tests

[Zolnai Tamás]

Hi guys,

I've got an idea too: automatically generated unit tests.
I think with a clang plugin we can generate unit tests for all
class/struct in the source code in build time. Build system can link
it as a simple unit test and run it directly after generation. If it
returns with no error it can be removed. If it returns an error the
test should be untouched to allow running it directly (without
regeneration).

These kind of tests gets in my mind now:
- Create an object and remove it (check no problem with destruction)
- Create and remove an object thousand of times (memory leak)
- Copy operator and copy constructor result is equivalent (operator== is needed)
- Copy an object, remove the original object (shallow copy)
- Create a const object, call all const method on it and check it remains equal.
- Getter and setter method: set a value and check the corresponding
getter method returns with the same value
-- Set values depending on the parameter type
--- int: end points of the value range, negative value, 0, positive value
--- string: empty string, dummy string, string with wild characters.

Best Regards,
Tamás


2015-06-03 15:33 GMT+02:00 Michael Meeks <michael.meeks at collabora.com>:
> Hi guys,
>
>         The ESC are interested in improving unit (and other automated) testing
> and are interested in concrete ideas for implementing new automated
> tests to prevent regressions. We hope to turn this into a proposal for
> the Board, which if approved -could- turn into a tender to fund more
> work in this area. Having said that writing unit tests is every
> developers' responsibility where feasible - so this ask focuses on new
> infrastructure.
>
>         It is noticeable that where there are existing tests & infrastructure,
> new tests are easier to create and often there are more of them - so are
> there places where we should work to create infrastructure ?
>
>         Is there something we can improve by throwing hardware at it ? as we
> have done for the crash-testing; if so what hardware is needed ?
>
>         Is there a large area of code that is completely un-tested or
> under-tested that you'd love us to invest in making test-able ?
>
>         Is there a test that currently only runs in an obscure setup /
> corner-case that we can invest in standardizing and making more easy to
> use ?
>
>         Constructive thoughts appreciated in reply here.
>
>         ATB,
>
>                 Michael.
>
> --
>  michael.meeks at collabora.com  <><, Pseudo Engineer, itinerant idiot
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice