it's why groovy has been used for years. Your test...

# announcements

[snowe]

it's why groovy has been used for years. Your tests can be named better.

[zpearce]

@karelpeeters I am curious about the spaces in test names hate. A short, readable sentence describing the test seems like a good idea to me.

[rook]

Spek lets you do that. I love it

[karelpeeters]

Tests are just functions like any other, so I don't like breaking the naming convention. We're all used to camelCase by now, so it's not that much more difficult to read. Short explanations can go in comments or in the KDoc, where you're not constrained to "one short sentence".

[karelpeeters]

And bit of a subjective thing but the backticks look rediculously ugly.

[zpearce]

I tend to agree with that actually. I only use them for test names though, and kotlin keywords imported from java, ofc

[snowe]

you shouldn't treat tests like other functions. They'll never be called on their own. They're meant to be a Spec (hence the name Spek) and as such they should describe what is being tested.

[snowe]

what's easier to read?

[snowe]

fun testGetAllEmploymentGapForAnApplicant_ApplicantIdNotFound_ThrowsNotFoundException() {

[snowe]

fun `Get of all Employment Gaps for an Applicant when ApplicantId not found throws NotFoundException`() {

[rook]

The one with red text is easier to read 🤔 (just teasing)

[snowe]

the first is an actual test name in our code base that somebody translated when converting from java.

[rook]

You should check out Spek, you can have nice names like that with having funky function names

[snowe]

We've tried to switch to spek.

[snowe]

it still doesn't work great with spring sadly.

[snowe]

and in spek it's still a string, but it's instead it's a parameter to a function. If you don't like the backtick naming then I doubt you'd like spek's naming conventions

[karelpeeters]

I don't really get what's being tested here, is there like a database.getAllEmploymentGapForApplicant(applicantId)?

[snowe]

yes.

[snowe]

the naming's terrible, I'm just pointing out that the longer a test name gets the more ridiculous camel case is.

[karelpeeters]

I'd argue you need to include the exact function name in the test though, don't try to rewrite that part with some spaces.

[karelpeeters]

That's just asking for trouble when that function gets renamed.

[karelpeeters]

Then you can't do much better than what you already have, maybe split out the throws part:

@Throws(NotFoundException::class)
fun getAllEmploymentGapForAnApplicant_ApplicantIdNotFound() {}

[snowe]

tests should describe what they're testing not the function they're testing.

[snowe]

here's the exact test

@Test(expected = NotFoundException::class)
    @Throws(Exception::class)
    fun testGetAllEmploymentGapForAnApplicant_ApplicantIdNotFound_ThrowsNotFoundException() {
        val employmentGaps = Lists.newArrayList(employmentGap())

        whenever(applicantDataService.findOne(applicantId)).thenReturn(Optional.empty())

        val allEmploymentGapsForAnApplicant = employmentDataService.getAllEmploymentGapsForAnApplicant(applicantId)

        assertNotNull(allEmploymentGapsForAnApplicant)
        assertFalse(allEmploymentGapsForAnApplicant.isEmpty())
        allEmploymentGapsForAnApplicant.forEach { dto -> verify(dto, findEmploymentGapById(employmentGaps, dto.employmentGapId)) }

    }

[snowe]

Of course the point of this discussion isn't this test. You can pick apart any bit of code. What happens when you get a test that calls multiple functions, it's an integration test. or it handles calls to a db to persist items and then check logic around reading it out of the db. Are you going to add every function call in to the name?

[karelpeeters]

You give it a short name without spaces, and you expand on that as needed in the KDoc.

[snowe]

You're putting doc comments on your tests? What happens when the test fails in your CI build?

[karelpeeters]

I rarely do, I just go look up the test name in the source and go from there.