<@U12AGS8JG>, when you use FunSpec, where do you d...

# kotest

[dave08]

@sam, when you use FunSpec, where do you do AAA (Arrange-Act-Assert)? All in the test blocks (using context just as a textual description), or spread out in the context blocks (possibly with instancePerLeaf)?

[sam]

I put most vals into the class body itself usually. And then the tests use those. Anything specific to a single test I keep inside test. I don't use context until the test file grows and I want to group

[dave08]

So basically JUnit+, and the test function names are complete in themselves, just using context to group them... interesting. And you use instancePerTest, I suppose?

[sam]

yep yep

[sam]

I think in the future I might move to free spec

[sam]

I like describe spec too actually, I've started to use that in some places

[sam]

so I'm like 95% fun spec, 5% describe spec

[christophsturm]

describe syntax is great if you have a subject and each test describes a part of it.

[christophsturm]

I like that it forces you to give your tests meaningful names

[dave08]

But then the test class name does that, no?

[dave08]

It sounds like FunSpec with the junit unitOfWork_situation_expectedResult naming strategy does the same... I just happened to have VERY long names with more complex situations, so setup ended up inside given or when sections to make things simpler...

[christophsturm]

isnt FunSpec and DescribeSpec the same except that contest is called describe and test is called it? for describe / it you have to really find a way to describe what the test does in one sentence (describe("the login manager") { it("creates a jwt token"} resulting in this test output:

* The Login Manager
  - creates a jwt token

[sam]

FunSpec, FeatureSpec, ExpectSpec, DescribeSpec, ShouldSpec are all the same except the key words change

[sam]

WordSpec is different layout. StringSpec / FreeSpec just use strings without keywords.

[sam]

BehaviorSpec is given when then, and AnnotationSpec is for JUnit migration

[dave08]

A bit of a crazy idea --- if the test styles would each be in a separate maven module, you could technically track how many users actually use each style, and maybe deprecate some... also it would force users to make a conscious choice to opt-in to a style and control the use of styles in a code-base. But managing them would be a bit more difficult.

[sam]

I like the idea, but it would also cause confusion as codebases would not compile until you added in the new modules. I think the 10 specs we have are regular enough that it works (4 types basically + annotations)

[dave08]

Well, it could be a gradual move, you could have the current module include them all, and give an alternative only including the framework and one for each style.

[sam]

true, like another framework that didn't include all styles

[LeoColman]

I use mostly ShouldSpec

[LeoColman]

And I use the context block a lot. Usually when I'm writing tests for different behaviors in the same class

[dave08]

You put setup code there, or just use context as a grouping construct @LeoColman?

[LeoColman]

I do, yeah