You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have two types of query test classes: classes which inherit from QueryTestBase, where a single model is shared across all tests, and non-shared (ad-hoc) tests, where each test creates its own model. This leads to a situation where the same "area" frequently has two test classes, e.g. JsonQuerySqlServerTest and AdHocJsonQuerySqlServerTest.
We could consider simply allowing non-shared tests inside regular QueryTestBase test classes; this would reduce the overall number of test classes, it would concentrate all the tests relating to a given area in a single class, we'd be able to put related tests next to each other, etc. Tests using non-shared models would automatically use a separate database (whose name could be derived from the shared-model one, e.g. by tacking on "NonShared").
One theoretical downside is that we would no longer parallelize pairs of shared and non-shared tests as we do now, but given the overall number of tests and classes we have, that seems to be really negligible.
We currently have two types of query test classes: classes which inherit from QueryTestBase, where a single model is shared across all tests, and non-shared (ad-hoc) tests, where each test creates its own model. This leads to a situation where the same "area" frequently has two test classes, e.g. JsonQuerySqlServerTest and AdHocJsonQuerySqlServerTest.
We could consider simply allowing non-shared tests inside regular QueryTestBase test classes; this would reduce the overall number of test classes, it would concentrate all the tests relating to a given area in a single class, we'd be able to put related tests next to each other, etc. Tests using non-shared models would automatically use a separate database (whose name could be derived from the shared-model one, e.g. by tacking on "NonShared").
One theoretical downside is that we would no longer parallelize pairs of shared and non-shared tests as we do now, but given the overall number of tests and classes we have, that seems to be really negligible.
/cc @maumar