[ditn]

Generally these are only used in test methods, which is fine. I've never seen anyone use them outside that.

[recursive]

What benefit do they provide in testing scenarios? I've never written Kotlin, but from an outsider's perspective, it seems like a slim benefit, outweighed by the cost of the mere existence of this syntactical oddity in the language's grammar.

[t-writescode]

When writing tests, you can name the methods more useful things, such as:

  class MyTestableClass {
    fun `methodName - when input does not parse to valid regex throw exception`() {

    }
  }

It's pretty clear what is under test in a situation like that. That's basically the only situation I ever see it used in (and would code-smell the heck out of it if I saw it in other circumstances).

People who are familiar with RSpec-style testing are very used to this sort of thing.

  describe MyTestableClass do
    context 'input parsing issues' do
      context 'when not valid regex' do
        it 'throws exception' do
          ...
        end
      end
    end
  end

Anecdotally, I've also found that such style naming for tests allows me to write out the desired names for all the tests ahead of time more easily and then implement them. That happens to be my flow.

[usrusr]

It's a place to put intetion that isn't so much of a second class citizen that it will likely be ignored and/or not updated if it ceases to be true. You want your test methods fine grained (many methods that each check one variation, instead of one method that checks a whole list of them) and every extra redundancy (method naming vs the variation of data actually passed vs documentation) increases the the chance of those redundancies getting out of sync.

In fact I've occasionally found myself writing reflection code to parse the test method name as input just to avoid that problem altogether (for name and data, not for documentation). And that was in plain Java even, the pattern could be far more useful with that kotlin naming freedom.

[irunmyownemail]

It reminds me of Spock tests written in Groovy. I have to help maintain a code base like that now at work where a Groovy zealot (who has moved on) convinced the teams to write tests in Groovy instead of Java.

When a test fails, the method name describes what it was supposed to do written out like a sentence enclosed in double quotes which seems like a win but not much of one.

When you need to add a new test or analyze if an existing test needs to be changed, you have to eyeball all the code in the test class because even with methods named with spaces, it's not always indicative of what it does.

With Java, I can sort a list of method names and have a better idea immediately what needs to be updated or added.

[grapesodaaaaa]

The test frameworks typically output the passing/failing function names. Adding spaces like this make them more human readable.

expectInternalServerErrorOnBadInput

Vs

expect internal server error on bad input

[erik_seaberg]

It’s better to quote a reserved word than to be unable to use it.

[wiseowise]

So that programmers have one more bikesheddibg reason, obviously.