After upgrading specs/specs2 to the newest specs2 stable version I found out really weird issue in my scala tests. In my "main" class (all of my test classes extend this one) I have before
and after
abstract class BaseSpec2 extends SpecificationWithJUnit with BeforeExample with AfterExample {
def before = startSqlTransaction
def after = rollbackSqlTransaction
[...]
}
before
starts transaction and after
ends it (I dont think I have to put code to show you how it works, If I am wrong please let me know).
I'm using JUnit in Eclipse to execute my tests in scala.
When I'm running them I get SqlError in some of them (the result of tests are not stable, what I mean is sometimes it ends up with success for one test, sometimes when this test won't go without error another will):
Deadlock found when trying to get lock; try restarting transaction
I think this error shows up, because before
starts transaction before every tests but after
does not close it for some reason. I debugged rollbackSqlTransaction
and startSqlTransaction
and it showed me that:
- When I start e.g 5 tests, transaction opens 5 times but closes only one time.
When I have added empty step
beetwen those 5 tests everythink worked fine.
When I have more than 5 tests it goes even more weird, e.g transaction starts 4 times then it closes then starts then closes etc. With 40 tests it opened 40 times and closed 29 times (its not stable too).
In my opinion for some reason tests are running so fast that executer is not able to close transaction, but I might be wrong. Is there anythink I can put in my code to slow them down? Or am I wrong and doing somethink else wrong? Also when I'm running my tests it seems like few of those tests are starting at the same time (they arent going one by one), but it might be just an ilusion in eclipse. Thanks for an answer and sorry for my bad english.
sequential
to your specification. – Ericafter
was not closing transaction after each test so they were probably sharing transaction (or I'm wrong about it and meaby newest specs2 trigger concurent execute). That said,sequential
helpt me cause now it works like it should (now they are goin one by one and that fixed issue probably). Thanks! ;) – lukaszrys