Describes

[dschinkel]

It doesn't appear Ava supports describes. Unless I'm missing it in the docs, I miss my describes.

[novemberborn]

Nope, that's on purpose. We don't think BDD necessarily makes your tests any better. Sorry to disappoint 😄

There's https://www.npmjs.com/package/ava-describe but I haven't checked how it's implemented.

I've started playing with ways of creating your own test() function on which you could install separate before / after hooks, which would allow for a BDD interface to be built properly. Keep an eye on #2435 for that.

(I'm closing this issue for housekeeping purposes, but let's keep the conversation going.)

[dschinkel]

And I'm sorry to go off on a rant, but I feel that's very short-sighted to just come to such a conclusion. Who's "we"? And who decides when BDD is useful or not and what BDD is?

Describes - not to you maybe, but it depends how you are testing and what you are testing.

A describe allows you to give a description of the feature under test. A spec name might do that too but sometimes we'd like to override that for may reasons.

And...to those who are viewing testing as a "per function" thing, and your test names should have the function name in them, you really aren't testing "per behavior" because by putting function names in your tests names themselves you're driving based on implementation details not behavior.

Also if there's a poor legacy codebase where the domain logic was named crappy, it'd be nice to write characterization tests and group them with describes that better describe the behavior of that messy codebase, before we start to refactor and rename stuff under the hood to read better and improve that codebase over time.

When I TDD, I go outside-in, and my tests describe behavior not implementation details so describes and test names go hand in hand when I'm reading groups of tests.

Relying on a third-party just to get describe in a testing framework sucks. This should be built-into Ava.

I think that it's fair to only support one level of describes, because nested to me is an indicator of a smell: that you need to break your features out into separate spec files anyway and the spec is doing too much but first level describes are important to have in any framework.

Also have you considered that describes are useful both at the command-line and in IDEs like IntelliJ once they do create an Ava plugin? We'll want describes in there so we can clearly see features and expand tests under each feature...using their test runner.

A lot of us don't want our tests coupled to filenames in fact, we want them coupled to behavior.. Which means My test or spec names do not and rightly should not always go 1:1 with filenames. You still may want a describe to differ more from that file name so that the output reads more detailed or even more clear.

It doesn't sound to me like this was well discussed yet.

[novemberborn]

AVA's been around for a long time already. We, the maintainers, have never seen the need to include other interfaces, at least in the core ava project itself.

The work in #2435 will make it possible for a BDD interface to be build on top of the core project, and we'd be more than happy to host that in our GitHub organization and publish it under our npm namespace (e.g. @ava/bdd).

[dschinkel]

Alright maybe I'll contribute once it's possible.

[m5x5]

I'm quite late to the discussion, but I just wanted to point out the issue at #222 for those who might come across this issue.