Vincent van Ravesteijn wrote:

> On Tue, Oct 27, 2015 at 12:56 AM, Uwe Stöhr <uwesto...@web.de> wrote:
>> Am 26.10.2015 um 16:51 schrieb Stephan Witt:
> 
>>>> If things are that easy why can't they be documented? That is why we
>>>> have the Development.lyx file, no? There ctest is not mentioned.

It will be mentioned soon. We had some sort of chicken and egg problem here: 
Those who knew how to run ctest in principle did not use windows, and those 
who used windows did not know enough about ctest. However, with the help of 
Vincent we made now a big step forward.

> I completely agree with you: if the tests are cannot be run easily for
> all of us, it is unfair to
> require to run the tests before committing everything. A test suite
> with 6000 tests, that runs
> for several days, requiring all possible kinds of dependencies, and
> using a lot of linux-specific
> scripting will not be very useful as a test that all developers should
> run before each commit.

I agree completely. Fortunately we are now getting the needed info about the 
specific problems when running the tests on windows, previously it always 
stopped at the point "it does not work". We should also update 
Development.lyx with every information that is needed for running the tests 
on all OSes.

> On the other hand, it is fair to make developers responsible for their
> own commits. So, if
> it can be avoided that a bug is introduced by running a single command
> from the command line,
> it makes sense to expect this from the developer.

Yes. This has always been my plan: Everybody should be able to run the 
simple tests (= unit tests, layout tests and tex2lyx tests) by typing a 
single command (or double clicking a batch file for the more GUI-centric 
people). And if this is possible, then you can start to use it to test your 
work in progress, especially if you work on tex2lyx, you implement something 
new, and then instead of testing manually a lot you can execute the tests, 
and if they pass then you can be sure that your change did not introduce 
major breakage. Once you get used to this style of development, you will 
produce better results in shorter time.

In case there was any misunderstanding: I am pretty sure that everybody 
agrees that the autotests (export tests, keytest etc) are not in a state 
that we can expect anybody to run them frequently.


Georg

Reply via email to