Am Sonntag, 22. November 2015 um 19:22:42, schrieb Georg Baum <georg.b...@post.rwth-aachen.de> > Guenter Milde wrote: > > > On 2015-11-21, Kornel Benko wrote: > >> Am Samstag, 21. November 2015 um 10:27:36, schrieb Georg Baum > >> <georg.b...@post.rwth-aachen.de> > >>> I still think it is a good idea to follow the KDE standard here (see > >>> above), and put all dedicated tests that can be run automatically > >>> unter top level autotests. > > > > I don't see the advantage at the current state of our "test suite". > > > > * we don't run the tests automatically (by chron script or triggered by > > any > > commit or on a dedicated test server) (while this would be an > > interesting option). > > > > * we don't have a separate set of tests to be run manually > > We do have some in development/mathmacros/. They contain instructions and > test cases for manual testing of math macros. > > > * we don't have that many tests. > > This is all no difference to KDE. There are projects with only autotests, > only manual tests, and I did not yet see one with more than a hand full of > tests. Still, there is a common structure, for each project it is > immediately clear where to look for certain tests, and if tests are extended > in the future it is clear how to do it. This does all apply to LyX as well. > > > Keep it simple now, adapt later if necessary. > > My first idea was to keep it simple, and to change the test machinery as > little as possible. That triggered opposition, because of the mixture of > tests and other stuff in lib (which is already there BTW, look at lyx2lyx). > > Then I suggested a single top level directory for tests, and I got > opposition because it is too general. > > Then I tried to implement the two level structure that was suggested on the > list, and it turned out that it does not work, because the current test > machinery is not prepared for tests from different top level directories > using the same name for subdirectories. In addition, this is now seen as too > complicated, so we are back to the beginning.
It is prepared now. I just did not add 'autotests/xy' to the list.
> I do not care whether the new dedicated export tests are implemented in a
> simple and suboptimal way, or whether we do first prepare for the future and
> re-organize the tests. What I do not like at all is to have a suboptimal
> solution that does still require some reorganization. This would be the
> combination of the drawbacks of both approaches. I would be happy with any
> of the two following solutions:
>
> 1) lib/tests/ (or any new directory not at top level) just for new dedicated
> export tests (will cause problems in cmake if other tests than export tests
> are added)
True, but the top-level is free for you.
> 2)
> - autotests/export/ for export tests (does not work with the current test
> machinery)
It is now possible.
All the tests there will be labeled by 'autotests' (additionally to label
'export').
> - autotests/functional/ for the compiled tests that are currently
> scattered in src
> - other subdirectories below autotests (for lyx2lyx, roundtrip etc) could
> be added in the future
> - tests/ for manual tests
>
> What do others think? I'd like a decision soon, because this is blocking the
> work on language nesting bugs.
>
I think autotests/export is just fine. The test-names look a little scary, e.g.
'export/export/somefile_pdf4_texF'
> Georg
Kornel
signature.asc
Description: This is a digitally signed message part.
