Comment by wubrr

9 hours ago

> It's socially painful to be the one constantly nagging people about names, but it really does take constant nagging to keep the quality high.

What do test names have to do with quality? If you want to use it as some sort of name/key, just have a comment/annotation/parameter that succinctly defines that, along with any other metadata you want to add in readable English. Many testing frameworks support this. There's exactly zero benefit toTryToFitTheTestDescriptionIntoItsName.

11 comments

wubrr

Reply
serial_dev  2 hours ago

Some languages / test tools don’t enforce testNamesLikesThisThatLookStupidForTestDescriptions, and you can use proper strings, so you can just say meaningful requirements with a readable text, like “extracts task ID from legacy staging URLs”.

It looks, feels, and reads much better.

  • lbreakjai  1 hour ago

    With jest (Amonsts others), you can nest the statements. I find it really useful to describe what the tests are doing:

        describe('The foo service', () => {

      describe('When called with an array of strings', () => {

        describe('And the bar API is down', () => {

          it('pushes the values to a DLQ' () => {
            // test here
          })

          it('logs the error somewhere' () => {
            // test here
          })

          it('Returns a proper error message`, () => {
            // test here
          })
        })
      })
    })

    You could throw all those assertions into one test, but they’re probably cheap enough that performance won’t really take a hit. Even if there is a slight impact, I find the reduced cognitive load of not having to decipher the purpose of 'callbackSpyMock' to be a worthwhile trade-off.

misja111  1 hour ago

It's funny, you are asking what test names have to do with quality, and you proceed with mentioning a really bad test name, 'toTryToFitTheTestDescriptionIntoItsName', and (correctly) stating that this has zero benefit.

Just like normal code, test methods should indicate what they are doing. This will help you colleague when he's trying to fix the failing test when you're not around. There are other ways of doing that of course which can be fine as well, such as describing the test case with some kind of meta data that the test framework supports.

But the problem that OP is talking about, is that many developers simply don't see the point of putting much effort into making tests readable. They won't give tests a readable name, they won't give it a readable description in metadata either.

6r17  9 hours ago

That's not the point of the article. The code should be readable no exception. The only reason we should be ysing x y z are for coordinates ; i should be left for index_what ; same goes for parameters ; they should also contain what unit they are on (not scale, but scale_float) only exception I see are typed languages ; and even then I'm occasionally asked a detail about some obscure parameter that we set up a year ago. I understand it can sound goofy, but the extra effort is made towards other people working on the project, or future self. There is no way I can remember keys or where I left the meaning of those, and there is no justification to just write it down.

Readability of the code makes a lot of it's quality. A working code that is not maintainable will be refactored. A non working cofe that is maintainable will be fixed.

yen223  2 hours ago

Kotlin has an interesting approach to solving this. You can name functions using backticks, and in those backticks you can put basically anything.

So it's common to see unit tests like

  @Test
  fun `this tests something very complicated`() {
    ...
  }

  • sfn42  1 hour ago

    You can do that in Java as well. Can't remember if it's exactly the same syntax

seadan83  8 hours ago

What kinds of things would you say are best as annotation vs in the test method name? Would you mind giving a few examples?

Also, are you a fan of nesting test classes? Any opinions? Eg:

Class fibrulatatorTest {

  Class highVoltages{

      Void tooMuchWillNoOp() {}
      Void maxVoltage() {}

} }

8note  9 hours ago

It's important to this article because its claiming that the name is coupled functionally to what the code tests -- that the test will fail if the name is wrong.

I don't know if any test tools that work like that though.

  • the_af  5 hours ago

    That's not what the article claims at all.

    It claims that, in order for tests to serve as documentation, they must follow a set of best practices, one of which is descriptive test names. It says nothing about failing tests when the name of the test doesn't match the actual test case.

    Note I'm not saying whether I consider this to be good advice; I'm merely clarifying what the article states.

the_af  5 hours ago

> What do test names have to do with quality?

The quality of the tests.

If we go by the article, specifically their readability and quality as documentation.

It says nothing about the quality of the resulting software (though, presumably, this will also be indirectly affected).