https://kotlinlang.org logo
Join Slack
Powered by
You personally only use one style all the time <@U...
# kotlintest
d
You personally only use one style all the time @sam?
l
I usually go with 
FreeSpec
and describe my test as I write it
But sometimes I use an adapted version of 
BehaviorSpec
, but in portuguese (we are replacing Cucumber with it)
d
Interesting, that's what I ended up doing up till now 🙂 . But Cucumber is a bit tough to replace with not so techy bosses... seeing all the code in between the tests.
l
I've never ever seen a Boss/ P.O. read a test scenario. It was always up to the devs/QA
It accomodates tester preference, but I sometimes use a different scenario based on what describes it best
I mean a different spec
d
That was the supposed point of Cucumber, no? To make tests readable by P.O.s ... I guess it didn't live up to its purpose then... I never found real-life good examples of well used test frameworks. I find the tutorials out there are all too made-up or simple, and the real projects seem to hack through tests a bit... or are not at all the typical business use of tests (like framework tests that are only applicable to the framework itself...). I've been writing tests for a while, but it would be nice to have more clear-cut rules and style guides... sometimes you can learn a lot from other people's ideas... All this is really a side-point and not related to the great work you guys are doing... just my personal search for "perfectionism" 😉
s
Well cucumber never really lived up to its promise because PO's can't write code.
And why would they, if they did they'd be a developer not a PO
At the moment I just keep my tests simple.
I think the "fancier" styles are there for people who have a clear preference for given/when/then or whatever
👌🏼 1
If you are unsure what to use then FunSpec or StringSpec all the way.
d
Thanks for the comments! One thing that always bothered me though, is if you already have explicit assertions why write the extra "should pass the test" or "should be equal to"... it seems like all the styles encourage that. I always thought the hierarchy helps put the test into context, but if it passes you won't see the extra test description, and if it doesn't, you end up looking more at the assertion's failure message...
s
I think the assertions are more lower level
so a test name might be "reg ex should match email" and then an assertion might be "should not be null" "should not be empty" "should contain @"
l
I think the idea for cucumber was that the scenario is abstract enough that even the PO can understand. But generally speaking, the PO should never care about how you writer your tests, so one can write a test that any dev can understand, with things like BehaviorSpec
I think cucumber solves the JUnit problem because in JUnit you have to describe the whole scenario in the function name
and there's no scope to reuse code, and the test scenario is not always clear
but given you can describe the test in a clearer fashion, I think that's the way to go, without the troubles that cucumber brings
d
True. The overhead that Cucumber incurs is not really worth it unless needed. Also true that test names are usually higher level in functional tests, but in unit tests I find they end up being too close to the assertion code...
Sometimes I just end up using StringSpec to put the test in context and it's content is just three blank line seperated sections for given/then/when... the nesting sometimes is rediculous I think, when all you have is one then and one when section inside each given...
l
I like to use the nesting to describe better what exactly I'm simulating in that scenario
Just 
every {  foo.bar() } returns { baz }
is not as clear as "Given the database contains an entity for the last day of the month"
d
In that case, true. But I wonder if that's really the most common case... I guess it depends on the type of projects. Also you're talking about functional tests, wereas unit tests are harder to spell out in a higher level way...
l
I'm talking about both. Either functional or unit tests, I usually find that Unit Tests with mocked dependencies should be described that way
Whereas simpler unit tests without too many shenanigans don't need it
d
Good point about mocked dependencies 👌🏼
l
And I think this is what we were discussing earlier, it's too much dependent on context and on tester's preference 😄
d
But you do sometimes skip the test description? Or do you always come up with some significant name for it?
I mean after you provided the context with given/then or describe/context etc...
l
I always come up with a significant name for it
It should have called "dependency" only once
It should equal the name passed as argument
I usually don't just go 
it shouldBe "Name"; verify { foo.bar() }
I find that giving it a meaning is better
When the test fails, I like to give the developer that will mantain it exactly what I was trying to do in that scenario.
Sometimes I'm like "Well... This is soooo simple"
But I usually go the long route to guarantee
d
I also felt the "Well... This is soooo simple", but you do have a point, sometimes we take things we understand for granted. I guess I could give it another try along that direction... thanks 🙂!
l
It does indeed become more verbose. But I'm very ok with that, as I communicate intent better
👌🏼 1
s
Doesn't this show how good KotlinTest is. It allow you the freedom to build tests in the way that you or your team thinks it best. Then someone comes along and invent a new test framework citing "simplicitly"... then they need to add "fixtures" and "scopes" and ways to initialise these fixtures and scopes. You end up with a mess. KotlinTest works with simple nested tests and your average every day variables.
👍🏼 1
2 Views
Open in Slack
PreviousNext
Powered by