Idea: run tests in transactions, roll them back
Hi all, in order to isolate tests from each other, we could consider starting a database transaction before running a test file, and then rolling back the transaction after the test file finished running. Then new objects (queues, users, groups, tickets) wouldn't need to be cleaned up manually at the end of a test, and the cleanup would even happen if a test aborts early. However, it'd only work for tests that don't want to establish their own DB connections, and not for tests that rely on inter-process communication (those couldn't share a transaction). Do you think this idea is worth pursuing? (afaict all of the supported DBs implement transactions just fine, except mysql on myisam, and DBI already provides a simple interface ($dbh->begin_work, $dbh->commit, $dbh->rollback)). Cheers, Moritz
Hello Moritz, this is a nice idea indeed. Technically this could be easily implemented in the UnitTestHelper as a new parameter (like RestoreSystemConfiguration) which also cleans up the cache after the test. It has some limitations (MyISAM, Selenium etc.), but could help with some things as well. Transactions are a topic that we should adress also in the regular code of OTRS at some point, but this might be a bigger effort. For now we could just use $DBObject->{dbh}->*() in the Helper object. If you want you can create a test implementation as a PR that actually tests the functionality of the rollback. Then I could merge it into master and check what our unit test servers say about it. :-P Best regards, mg Am 05.06.15 um 10:08 schrieb Moritz Lenz:
Hi all,
in order to isolate tests from each other, we could consider starting a database transaction before running a test file, and then rolling back the transaction after the test file finished running.
Then new objects (queues, users, groups, tickets) wouldn't need to be cleaned up manually at the end of a test, and the cleanup would even happen if a test aborts early.
However, it'd only work for tests that don't want to establish their own DB connections, and not for tests that rely on inter-process communication (those couldn't share a transaction).
Do you think this idea is worth pursuing?
(afaict all of the supported DBs implement transactions just fine, except mysql on myisam, and DBI already provides a simple interface ($dbh->begin_work, $dbh->commit, $dbh->rollback)).
Cheers, Moritz
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
-- Martin Gruner Senior Developer R&D OTRS AG Bahnhofplatz 1a 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel Grenzenlose Kommunikation mit der OTRS Business Solution™! Bereichern Sie Ihren IT Support und Kundenservice mit smarten Business Features! https://www.otrs.com/solutions/otrs-business-solution-on-premise/?lang=de/#O...
On 06/15/2015 09:18 AM, Martin Gruner wrote:
Hello Moritz,
this is a nice idea indeed. Technically this could be easily implemented in the UnitTestHelper as a new parameter (like RestoreSystemConfiguration) which also cleans up the cache after the test.
It has some limitations (MyISAM, Selenium etc.), but could help with some things as well. Transactions are a topic that we should adress also in the regular code of OTRS at some point, but this might be a bigger effort. For now we could just use $DBObject->{dbh}->*() in the Helper object.
If you want you can create a test implementation as a PR that actually tests the functionality of the rollback. Then I could merge it into master and check what our unit test servers say about it. :-P
And here it is: https://github.com/OTRS/otrs/pull/607 If the smoke tests come out green (or green enough for your taste ;-), I'd propose an API like my $ScopeGuard = $Self->CleanupOnDestroy(); ( or maybe $HelperObject->CleanupOnDestroy ) and when $ScopeGuard goes out of scope (due to the test file being done), its DESTROY method will roll back the current transaction and clean the cache. Depending on the scoping of these objects, this behavior might go into the UnitTest or UnitTest::Helper objects -- but currently I don't have a good overview whether they live just for one test file, or longer. Cheers, Moritz
participants (2)
-
Martin Gruner -
Moritz Lenz