It would definitely improve the visibility of test failures if it was easier to run just a suitable subset of tests.
Aside from better parametrization of tests, the tests would also benefit from being declared in the same package as the most relevant tested classes (when meaningful), instead of being under the org.h2.test prefix. Being able to use package-private methods when writing tests is often a great advantage. Initially, only the build system needs to be adjusted (to keep the compiled test classes in a separate directory from the "main" class files), the actual migration of test classes can be done gradually later. Tomas On Thursday, September 1, 2016 at 10:04:47 AM UTC-4, Sergi Vladykin wrote: > > H2 tests actually run quite a long time. We may have to split tests into > multiple parts to avoid these timeouts. > > I think it is a good idea to split the tests into matrix [1] by settings: > > - in-memory + embedded > - in-memory + networked > - on-disk + embedbed > - on-disk + networked > > This way we will have a clearer picture of what exactly behaves badly. > > [1] https://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix > > Sergi > . > > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
