<@U3K0MNQR1> If I may join :wink: I’ve tried and it was cool but it wasn’t sufficient because it di...

# spek

[kasper.kondzielski]

@dsgryazin If I may join 😉 I’ve tried and it was cool but it wasn’t sufficient because it didn’t allow to have unlimited nesting of test cases. On the other hand it was very easy to write custom Specification which does based on its based specification class. (But it performed poorly)

[dsgryazin]

Thanks for reply! If you have any open sources test to look at, that would be great=)

[kasper.kondzielski]

Unfortunately it was on private repository 😞

[dsgryazin]

We do practise spek in non android targets.
I personally agree with the spock ideology, that deep nesting is not a scalabe solution.
https://github.com/spockframework/spock/issues/106

[dsgryazin]

Wonder if someone used to test complicated, very stateful stuff with spek and if it was ok in maintenance

[kasper.kondzielski]

We used this kotlin-tests with our custom spec to test IMO quite complicated state machine and it was very good, mainly because of those nestings

[kasper.kondzielski]

Here is a snippet from our code base:

assertBluetoothDialogGone()
            assertLoaderVisible()
            assertMapSelectorGone()
            assertMapVisible(firstMap)
            nestTestWithBefore("and map is loaded", { events.accept(OfficeMap.Event.MapLoaded) }) {
                andMapSelectorOpened {
                    assertMapSelectorVisible()
                    andMapIsSelected(secondMap) {
                        assertMapVisible(secondMap)
                        assertMapSelectorGone()
                        andApiReturnsError {
                            assertDefaultErrorVisible()

[kasper.kondzielski]

Hard to past it here so it looks equally good as in idea but I hope you get the point.