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
I've started working on a build macro based version that'll make the users write implements tink.unittest.TestSuite in the long run (I propose deprecating the current style for now). The main motivation was really to support the implementation of #17. Also, it'll allow making some transformations, like the one brought about by @:asserts.
So I would like to use the opportunity to see what we could do about some of the syntactic noise (e.g. having to have return asserts.done() in a fully synchronous test - which is the overwhelming majority of them - is a bit annoying) and simplifying things for newcomers.
I see two solutions to then express async tests:
Implicit: If the function returns a future, wait for it (also, if it returns a promise then report failure).
Explicit: Only tests decorated with @:async (for example) will be treated as such. In this case we have two options in turn:
Pass a done:()->Void that allows terminating the test
Expect a future in return. On first glance this seems nicer, because it makes the user return a single future rather than potentially calling done from various branches, but if the test is more easily written in such a way they'll just write return Future.irreversible(done -> ...) and have the same structure anyway. Also not having to learn about futures to write async tests has some appeal (this should not be decisive, but if both approaches are equally good from an experienced tink user's perspective, we can go for the one that's more approachable to newbies).
We could support all the solutions too, although I'm not sure that's practical. People gravitate towards consistency and as far as test suites go I can see the appeal of not having to figure out which style something is written in ^^
The text was updated successfully, but these errors were encountered:
I've started working on a build macro based version that'll make the users write
implements tink.unittest.TestSuite
in the long run (I propose deprecating the current style for now). The main motivation was really to support the implementation of #17. Also, it'll allow making some transformations, like the one brought about by@:asserts
.So I would like to use the opportunity to see what we could do about some of the syntactic noise (e.g. having to have
return asserts.done()
in a fully synchronous test - which is the overwhelming majority of them - is a bit annoying) and simplifying things for newcomers.I see two solutions to then express async tests:
@:async
(for example) will be treated as such. In this case we have two options in turn:done:()->Void
that allows terminating the testdone
from various branches, but if the test is more easily written in such a way they'll just writereturn Future.irreversible(done -> ...)
and have the same structure anyway. Also not having to learn about futures to write async tests has some appeal (this should not be decisive, but if both approaches are equally good from an experienced tink user's perspective, we can go for the one that's more approachable to newbies).We could support all the solutions too, although I'm not sure that's practical. People gravitate towards consistency and as far as test suites go I can see the appeal of not having to figure out which style something is written in ^^
The text was updated successfully, but these errors were encountered: