I'm working on integration tests using the Databas...
# testing
b
I'm working on integration tests using the Database with TestBox and have a working test (even wrapped in a transaction so changes are rolled back automatically), but I keep seeing references to calling
super.beforeAll()
or
super.afterAll()
in test bundles referenced in documentation and examples I'm reading that inherit from a Base Test Class (that inherits from the Testbox Base Spec). Can someone explain to me what this means: "This also helps parent classes enforce their setup methods are called by annotating the methods with
@beforeAll
. No more forgetting to call
super.beforeAll()
!" - from this page: https://testbox.ortusbooks.com/in-depth/life-cycle-methods/annotations I am not doing this (not calling super.beforeAll etc, anywhere), but my tests are working fine. Am I missing something or should I be calling that somewhere? When and where do you need to call the
super.[LifeCycleMethods]()
? My class inheritance: testbox.system.BaseSpec -> myBaseTestClass (initializes application variables/test setup and does not call super.beforeEach etc.)
Sorry, one more question: Do tests in TestBox run in parallel or no?
e
Not parallel by default.
πŸ‘ 1
As for the annotation, it’s an option when working with inheritance to not need to call the
super
methods. If your tests are working, no need to change anything.
πŸ™ 1
b
Ok, thank you. I kept seeing it everywhere and started to wonder if I needed it, but everything is working.
b
To be clear, you CAN run your tests in parallel, but you must be careful. Any tests that aren't thread safe or expect to run in a specific order may fail
b
Thanks for the call out. For now, I'd prefer tests run synchronously, so I'm glad that's the default. I'll take deterministic and easy to understand over faster in my case.
b
When you have an actual method called
beforeAll()
you β€’ only can have one of them (duh) β€’ you must call the
super.beforeAll()
or stuff won't work however, when you do this
Copy code
@beforeAll
funnction someRandomMethodWhoCaresWhatItIsCalled() {
}

@beforeAll
funnction anotherOne() {
}

@beforeAll
funnction anotherOneBitesTheDust() {
}
you can β€’ have as many before all methods as you like β€’ none of them need to make any super calls since they don't actually override the base method
πŸ‘€ 1
That's what the note in the docs was trying to convey
If I had a dollar every time I've seen a test suite not behaving correctly because someone was overriding the base lifecycle methods and not delegating to the super, I'd have several dollars
b
You may get another dollar from me πŸ˜„ Hmmm...good to know and ty for the example. So just to make sure I'm not shooting myself in the foot, if I have a BaseTest class that inherits from the TestBox BaseSpec and just sets up variables, but no
beforeAll
call, I have no need to call super.beforeAll() (pretty sure this is right), correct? However if I did have a beforeAll in my BaseTest class, does that mean I need to call super.beforeAll in it or in a constructor init in order to bring maybe a TestBox's BaseSpec
beforeAll
I'm inheriting from into the mix?
b
That is correct
πŸ™ 1