Hello Cyrille, On Wed, May 8, 2013 at 1:28 AM, Cyrille Artho <c.ar...@aist.go.jp> wrote:
> Hi Elmar, > I think your plan covers the question "HOW do we want to unit test the > software" well. However, we have not thought much about the "WHAT do we > want to test?" question. Essentially, we need to think about which > classes/functions to test first. > > I think it is not realistic to aim for a high test coverage with software > as large as LyX. Unit tests make sense in certain cases and less in others. > So we should identify these use cases first, and start with a few selective > unit tests. We can then grow them as we see fit. > > Yes, I share this vision of let the tests grow. That's the reason, why it's only a small plan. A plan can't tell the people what they want to test. It's the decision of the people themself, driven by different motivations. A plan can only leverage. There are at least two questions: * What do I want to test? * What can I test at all, at reasonable costs. When I write new software in other languages, I write code and tests side by side, resulting in a test coverage of approximately 100%, without extra costs, as I need to run the code anyway. Writing tests for existing software, is much more difficult. In the beginning that are extra costs. They pay on the long run by fewer bugs. I have to weight. > For user-driven actions (LFUNs), LyX already has a test framework. > However, these tests do not cover internals of LyX. > > Right, unit testing is only one class of testing. That's why it has it's own path "tests/unit". Gui testing needs completely different approaches and more support by testing framewoks resulting in "tests/gui" or similar. Probably there are also tools to cover memory leaks or performance. > Which internals do not require a complex sequence of actions (or a complex > internal state) to be tested? (Those that do are maybe better covered with > other types of tests.) Where has the code changed often in the past, and is > expected to change often in the future? What kinds of (internal) functions > are often covered by bug reports and thus warrant better test automation? > Likely the most error-prone corners are the haredest to tests, because of the same reasons. To get started, I would need to do some more simple cases first. > > I hope some of the veteran developers can help answer these questions. > > \Elmar -- Elmar Hinz Freiherr-vom-Stein-Str. 1 33014 Bad Driburg TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m
