Nested scopes

[CaringDev]

In #30 @asbjornu brings up the idea of having nested test scopes, which should allow for something like

"Describe Foo".x(() => {
   "it barks".x(() => ...);
   "it moohs".x(() => ...);
});

respectively

Spec("Foo", () => {
  Spec("barks", () => ...);
  Spec("moohs", () => ...);
});

similar to nested describe / test / it in some JS test frameworks.

While I'm not sure this is worth implementing or using, given the complexities (order of evaluation, scoping, async) with the 'deferred' execution of the tests, I'm willing to explore solutions.

Maybe we could rather 'implement' that feature with nested (static) test classes?

[asbjornu]

The important point of having nested scopes is not simply to provide a visual hierarchy, but to allow data from outer scopes to be used in the inner scopes. That becomes difficult and very convoluted with nested classes.

[CaringDev]

I think I see where you're headed and I agree, that there's potential value... but I don't know (yet) how we would implement that.
And I have to say that I'm still skeptical... ambient state is almost always a recipe for disaster 😈 unless we can reuse existing 'infrastructure', that is.
Could you come up with a short, compelling usage example (like you did for the Test case)?

[asbjornu]

Since nesting is possible in other BDD frameworks such as RSpec and Jest, I think it provides ample evidence that this is a wanted and much-used feature in the world of automated software testing. In RSpec and Jest, I use nesting all the time. It's simply how you write tests in those frameworks.

But to be specific about my need in relation to LambdaTale, I'm using it primarily to write long-form integration tests (almost, but not quite E2E tests, but at the API level) for legacy systems that are hard to test by more isolated unit tests. I would of course like for everything to be testable at the isolated unit level, but the code needs to be refactored to get there. To refactor the code with confidence, the codebase must be well covered by tests.

So, with LambdaTale, I like to write long scenarios of interactions with various HTTP API resources to ensure that the scenarios continue working after refactoring. Some scenarios overlap and require certain foundational HTTP API resources to be created before other functionality is tested. Creating these foundational HTTP API resources in an outer scope and then using them in an inner scope, would make the reuse of properties from these resources, such as identifiers, much easier.

Nesting would also establish an alternative and much more elegant way to provide hierarchy and structure to tests, which today is only solvable by the imho ugly way of having to nest classes within each other. Just writing nested Spec("description", …) statements is so much cleaner, requires less boilerplate, and would make both the test classes and the test results easier to read and understand.