10 ms·

I share this ideal, but also have to gripe that "descriptive test name" is where this falls apart, every single time. Getting all your teammates to quit giving

I share this ideal, but also have to gripe that "descriptive test name" is where this falls apart, every single time. Getting all your teammates to quit giving all their tests names like "testTheThing" is darn near impossible. 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. As soon as the nagging stops, someone invariably starts cutting corners on the test names, and after that everyone who isn't a pedantic weenie about these things will start to follow suit. Which is honestly the sensible, well-adjusted decision. I'm the pedantic weenie on my team, and even I have to agree that I'd rather my team have a frustrating test suite than frustrating social dynamics. Personally - and this absolutely echoes the article's last point - I've been increasingly moving toward Donald Knuth's literate style of programming. It helps me organize my thoughts even better than TDD does, and it's earned me far more compliments about the readability of my code than a squeaky-clean test suite ever does. So much so that I'm beginning to hold hope that if you can build enough team mass around working that way it might even develop into a stable equilibrium point as people start to see how it really does make the job more enjoyable.

tpoacher 2y ago
Obviously this is slightly implementation dependent but if your tests are accompanied by programmatic documentation (that is output together with the test), doesn't that eliminate the need for a descriptive test name in the first place? If anything, in this scenario, I wouldn't even bother printing the test names, and would just give them generated identifier names instead. Otherwise, isn't it a bit like expecting git hashes to be meaningful when there's a commit message right there?
- crabbone 2y ago
  The article addresses this: there's no systematic enforcement of documentation currency. It may accidentally and unbeknownst to its authors become outdated. Anyways, as already mentioned earlier: unit tests are code and all quality criteria that apply to any other code apply to unit tests too. We expect identifiers used in code to help understand the code no matter if it's the name of a unit test or any other entity in our program. NB. To me this argument seems as bizarre as disputing washing your hands after using the bathroom. Why would anyone think that they should get a pass on code quality standards when writing unit tests? This just doesn't make sense...
  - tpoacher 2y ago
    Replying slightly late as I didn't see this on time ... But I don't get the argument. Perhaps we're talking about different things (or have different mental anchors in mind)? Giving python unittest syntax as an example, how does having a test called def test_myMethod_caseWhereZeroInputsAreGiven(): ... provide better currency / documentation guarantees than def test_case000135(): """ Tests: myMethod Date: 2024-10-23 Commit base: edb78go9 Summary: Tests case where zero inputs are given. Details: ... """ As for quality criteria, I'm not necessarily claiming the naming scheme is overwhelmingly better, but except in the very limited and unrealistic scenario where you only need to write a single test per method, unwieldy test method names can cause more confusion than clarity, so I don't think index-based naming schemes complemented by documentation headers are 'worse' either. I don't think the standard good variable naming rules apply much here, because in general variable names largely rely on context to be meaningful, and should only be as minimally descriptive as required to understand their role in that context, whereas a test needs to be sufficiently descriptive to describe what is being tested AND provide the necessary context. I don't think the bathroom analogy is good here either. I'm not arguing for sloppiness or bad code hygiene. A "better" analogy would be someone complaining about people not using the provided towels like people have always been doing, when the initial argument is that the towels in this particular room seem dirty and there's a perfectly fine airdryer "right there". Hence the answer "why does anyone think they get a pass washing their hands on a towel" just sounds bizzare to me, when the topic is appropriateness of sanitation method, not cleanliness itself. (note: not being argumentative, I hope my tone does not come across as such; if you do bump onto this again and think I'm misinterpreting or missing some finer point entirely, I'd be interested to hear it)
zoover2020 2y ago
Have you considered a linter rule for test names? Both Checkstyle and ESLint did great work for our team
wubrr 2y 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.
- 6r17 2y 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.
  - wubrr 2y ago
    I'm obviously replying to GP's specific comment on test names. I fail to see how your reply relates to my comment at all.
- 8note 2y 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 2y 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.
yourapostasy 2y ago
> ...increasingly moving toward Donald Knuth's literate style of programming. I've been wishing for a long time that the industry would move towards this, but it is tough to get developers to write more than performative documentation that checks an agile sprint box, much less get product owners to allocate time test the documentation (throw someone unfamiliar with the code to do something small with it armed with only its documentation, like code another few necessary tests and document them, and correct the bumps in the consumption of the documentation). Even tougher to move towards the kind of Knuth'ian TeX'ish-quality and -sophistication documentation, which I consider necessary (though perhaps not sufficient) for taming increasing software complexity. I hoped the kind of deep technical writing at large scales supported by Adobe Framemaker would make its way into open source alternatives like Scribus, but instead we're stuck with Markdown and Mermaid, which have their place but are painful when maintaining content over a long time, sprawling audience roles, and broad scopes. Unfortunate, since LLM's could support a quite rich technical writing and editing delivery sitting on top of a Framemaker-feature'ish document processing system oriented towards supporting literal programming.
ronnier 2y ago
I’d rather leave a good comment instead of good test names. I mean do both, but a good comment is better imo. All I really care about is comments anymore. Just leave context, clues, and a general idea of what it’s trying to accomplish.
- lallysingh 2y ago
  Four test failures in different systems, each named well, will more quickly and accurately point me to my introduced bug than comments in those systems. Identifiers matter.
hinkley 2y ago
It’s practically a sociology experiment at this point: half of the time when I suggest people force themselves to use a thesaurus whether they think they need it or not, I get upvoted. And half the time I get downvoted until I get hidden. People grab the first word they think of. And subconsciously they know if they obsess about the name it’ll have an opportunity cost - dropping one or more of the implementation details they’re juggling in their short term memory. But if “slow” is the first word you think of that’s not very good. And if you look at the synonyms and antonyms you can solidify your understanding of the purpose of the function in your head. Maybe you meant thorough, or conservative. And maybe you meant to do one but actually did another. So now you can not just chose a name but revisit the intent. Plus you’re not polluting the namespace by recycling a jargon word that means something else in another part of the code, complicating refactoring and self discovery later on.
gorgoiler 2y ago
Hah, I swing the other way! If module foo had a function bar then my test is in module test_foo and the test is called test_bar. Nine times out of ten this is the only test, which is mostly there to ensure the code gets exercised in a sensible way and returns a thing, and ideally to document and enforce the contract of the function. What I absolutely agree with you on is that being able to describe this contract alongside the function itself is far more preferable. It’s not quite literate programming but tools like Python’s doctest offer a close approximation to interleaving discourse with machine readable implementation: def double(n: int) -> int: “””Increase by 100% >>> double(7) 14 “”” return 2 * n
- hu3 2y ago
  > If module foo had a function bar then my test is in module test_foo and the test is called test_bar. Same. This is a good 80/20 in my experience. Testing the happy paths is already very rewarding.
deleted 2y ago
[deleted]
misja111 2y ago
Thanks for the hint about Knuth's literate programming! I hadn't heard about it before but it immediately looks great. (For those of us who hadn't heard about it before either, here is a link: https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming) About your other point: I have experienced exactly the same. It just seems impossible to instill the belief into most developers that readable tests lead to faster solving of bugs. And by the way, it makes tests more maintainable as well, just like readable code makes the code more maintainable anywhere else.
yesbabyyes 2y ago
As a fan of literate programming, I hope this could be a tool in the box for Node.js developers: Testy is basically doctests for Node.js, building off JSDoc's @examples stanza. I would be honored by anyone checking it out: https://github.com/linus/testy https://github.com/linus/testy
- paxcoder 2y ago
  [dead]
ojkelly 2y ago
Test names are one of those things that are painful because it’s obvious to you as you write it, but there’s an extra hassle to switch gears in your head to describe what the contents of the test is doing. It is really valuable when they are named well. I’ve found this is where LLM can be quite useful, they’re pretty good at summarising. Someday soon I think we’ll see a language server that checks if comments still match what they’re documenting. The same for tests being named accurately.
- pydry 2y ago
  I've never seen this as a problem. If you're doing TDD and you have a scenario in mind, you describe that scenario in the name of the test. If you're writing the test after then yeah, maybe it's hard, but that's one of the many reasons why it's probably better to write the test before and align it with the actual feature or bugfix you're intending to implement.
  - mewpmewp2 2y ago
    Maybe also why TDD is hard for me because I only truly start to think or visualize when I'm writing the actual code. I don't know if it's ADHD or what it is, but writing requirements, tests before hand, is just not my forte. It's like I only get dopamine from when I build something and everything else feels frustrating.
    - crazygringo 2y ago
      I used to be like that sometimes. Then I started realizing I'd get the function 90% complete and discover an edge case and have to start over in a way that could handle the edge case. Sometimes this could happen twice. Documenting your requirements by writing the tests in advance is of course painful because it forces you to think more upfront about the edge cases in advance. But that's precisely why it saves time in the long run, because then it makes it a lot more likely you can write the function correctly from the start.
gus_leonel 2y ago
Test names should be sentences: https://bitfieldconsulting.com/posts/test-names https://bitfieldconsulting.com/posts/test-names
- nuancebydefault 2y ago
  In fact that is not very hard to do and provides a great advantage!
- wnmurphy 2y ago
  100%. Test names should include the word "should" and "when". Then you get a description of the expected behavior.
- wubrr 2y ago
  Shallow/meh, article. Demonstrates complete lack of familiarity with many popular testing frameworks/approaches, and proposes a subpar solutions for problems that have already been solved in superior ways. Your test description/documentation should be sentences, but there is absolutely zero reason to try to encode that into the name of your test function. Not to mention this article then suggests using another tool to decode this function name into a proper sentence for reporting... ok now you completely lost the ability to ctrl+f and jump to the function... terrible advice all around. Why not just use a testing framework that actually supports free-form sentence descriptions/documentation for your tests?
  - bunderbunder 2y ago
    If my unit testing framework supports free-form sentence descriptions, I'll use it. But I won't use that feature as a wedge issue. It doesn't bother me all that much to have test functions with names like `test_transaction_fails_if_insufficient_funds_are_available()`. Other features of the test framework might have a much bigger impact on my developer experience.
    - wubrr 2y ago
      Pretty much every major language/framework now supports free-form test names/descriptions, including JUnit, which is referenced in the article ^ (again, highlighting the author's ignorance). Just because something doesn't bother you personally doesn't mean it's a good thing to follow, especially when its clearly inferior to other options. > It doesn't bother me all that much to have test functions with names like `test_transaction_fails_if_insufficient_funds_are_available() I mean, that's one example where you have one outcome based on one parameter/state. Expand this to a 2-field outcome based on 3 state conditions/parameters and now you have a 100-character long function name.
paxcoder 2y ago
[dead]
macspoofing 2y ago
>Getting all your teammates to quit giving all their tests names like "testTheThing" is darn near impossible. You can do better than "testTheThing". Have your team (or a working group composed of your team, if your team is too big) put together a set of guidelines on naming conventions for unit test methods. Have your team agree to these conventions (assumption is that the working group would have consulted with rest of team and incorporated their feedback). Then make that part of the code review checklist (so you aren't the one that is actually enforcing the policy). Do spot checks for the first little while, or empower some individuals to be responsible for that - if you really want to. Do a retrospective after a month or 2 months to see how everyone is doing and see how successful this initiative was.
crabbone 2y ago
Bad work practices create bad social dynamics. If someone on the team isn't pulling their weight by being lazy, I don't see a reason to like that person if I'm their team member.
nzach 2y ago
>Getting all your teammates to quit giving all their tests names like "testTheThing" is darn near impossible. Sometimes people are pretty bad a coming up new names, but selecting a good name given some options generally isn't a big problem. So maybe we should create a kind o LLM linter for this situation ? The prompt could be along the lines: "Given this function: <FUNCTION> This unit test: <UNIT TEST> And these naming considerations: <NAMING GUIDE> Is the current test name a good option? What would be some better options?" I did some quick testing and it seems work to reasonably well. It doesn't create anything mind-blowing but at least it seems to provide some consistent options.
- nzach 2y ago
  Here is a really bad POC for golang tests, if anyone is interested: https://github.com/nzachow/lmlinter https://github.com/nzachow/lmlinter Right now it just prints the prompt in the terminal.
flerchin 2y ago
You know what they say: Naming things is one of the 2 hardest problems in computer science. The other one being cache invalidation and off by one errors.
- SAI_Peregrinus 2y ago
  Or the async version There are three hard problems in computer science: 1) Naming things 2) Cachoncurr3)e invalidation ency 4) Off-by-one errors
  - Jerrrrrrry 2y ago
    this is incredibly unnerving of a comment, thank you.
TheSoftwareGuy 2y ago
This is one area where a BDD style framework like catch2[0] really shines, IMO. The way tests are written in this style naturally lends itself to self-documenting each branch [0]: https://github.com/catchorg/Catch2 https://github.com/catchorg/Catch2
nuancebydefault 2y ago
I used to be the weenie who always said we need to define nomenclature before things get silly names (hence very very early to prevent those to become the norm for legacy reasons) and use proper naming for everything, such that code would read like a novel (yes that is a stretch). But indeed it tended to lead to frustrating social dynamics in stead of happy romcom scripts. So I gave up on most of it. That said, my opinion about test code is, it exists to find bugs or steer away from regression. API descriptions, together with a design with some graphs, should be formal and clear enough to understand code usage. I don't want to figure out the usage of fwrite() by going through its elaborate test suite.
wryoak 2y ago
I encourage my teams to include the project tracker ticket name of the requirement or bug fix in the name. Eg, “XYZ12” -> fn { … } // test for value always being positive Of course some test libraries make this approach difficult.

tpoacher 2y ago

Obviously this is slightly implementation dependent but if your tests are accompanied by programmatic documentation (that is output together with the test), doesn't that eliminate the need for a descriptive test name in the first place? If anything, in this scenario, I wouldn't even bother printing the test names, and would just give them generated identifier names instead. Otherwise, isn't it a bit like expecting git hashes to be meaningful when there's a commit message right there?

crabbone 2y ago
The article addresses this: there's no systematic enforcement of documentation currency. It may accidentally and unbeknownst to its authors become outdated. Anyways, as already mentioned earlier: unit tests are code and all quality criteria that apply to any other code apply to unit tests too. We expect identifiers used in code to help understand the code no matter if it's the name of a unit test or any other entity in our program. NB. To me this argument seems as bizarre as disputing washing your hands after using the bathroom. Why would anyone think that they should get a pass on code quality standards when writing unit tests? This just doesn't make sense...
- tpoacher 2y ago
  Replying slightly late as I didn't see this on time ... But I don't get the argument. Perhaps we're talking about different things (or have different mental anchors in mind)? Giving python unittest syntax as an example, how does having a test called def test_myMethod_caseWhereZeroInputsAreGiven(): ... provide better currency / documentation guarantees than def test_case000135(): """ Tests: myMethod Date: 2024-10-23 Commit base: edb78go9 Summary: Tests case where zero inputs are given. Details: ... """ As for quality criteria, I'm not necessarily claiming the naming scheme is overwhelmingly better, but except in the very limited and unrealistic scenario where you only need to write a single test per method, unwieldy test method names can cause more confusion than clarity, so I don't think index-based naming schemes complemented by documentation headers are 'worse' either. I don't think the standard good variable naming rules apply much here, because in general variable names largely rely on context to be meaningful, and should only be as minimally descriptive as required to understand their role in that context, whereas a test needs to be sufficiently descriptive to describe what is being tested AND provide the necessary context. I don't think the bathroom analogy is good here either. I'm not arguing for sloppiness or bad code hygiene. A "better" analogy would be someone complaining about people not using the provided towels like people have always been doing, when the initial argument is that the towels in this particular room seem dirty and there's a perfectly fine airdryer "right there". Hence the answer "why does anyone think they get a pass washing their hands on a towel" just sounds bizzare to me, when the topic is appropriateness of sanitation method, not cleanliness itself. (note: not being argumentative, I hope my tone does not come across as such; if you do bump onto this again and think I'm misinterpreting or missing some finer point entirely, I'd be interested to hear it)

zoover2020 2y ago

Have you considered a linter rule for test names? Both Checkstyle and ESLint did great work for our team

wubrr 2y 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.

6r17 2y 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.
- wubrr 2y ago
  I'm obviously replying to GP's specific comment on test names. I fail to see how your reply relates to my comment at all.
8note 2y 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 2y 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.

yourapostasy 2y ago

> ...increasingly moving toward Donald Knuth's literate style of programming. I've been wishing for a long time that the industry would move towards this, but it is tough to get developers to write more than performative documentation that checks an agile sprint box, much less get product owners to allocate time test the documentation (throw someone unfamiliar with the code to do something small with it armed with only its documentation, like code another few necessary tests and document them, and correct the bumps in the consumption of the documentation). Even tougher to move towards the kind of Knuth'ian TeX'ish-quality and -sophistication documentation, which I consider necessary (though perhaps not sufficient) for taming increasing software complexity. I hoped the kind of deep technical writing at large scales supported by Adobe Framemaker would make its way into open source alternatives like Scribus, but instead we're stuck with Markdown and Mermaid, which have their place but are painful when maintaining content over a long time, sprawling audience roles, and broad scopes. Unfortunate, since LLM's could support a quite rich technical writing and editing delivery sitting on top of a Framemaker-feature'ish document processing system oriented towards supporting literal programming.

ronnier 2y ago

I’d rather leave a good comment instead of good test names. I mean do both, but a good comment is better imo. All I really care about is comments anymore. Just leave context, clues, and a general idea of what it’s trying to accomplish.

lallysingh 2y ago
Four test failures in different systems, each named well, will more quickly and accurately point me to my introduced bug than comments in those systems. Identifiers matter.

hinkley 2y ago

It’s practically a sociology experiment at this point: half of the time when I suggest people force themselves to use a thesaurus whether they think they need it or not, I get upvoted. And half the time I get downvoted until I get hidden. People grab the first word they think of. And subconsciously they know if they obsess about the name it’ll have an opportunity cost - dropping one or more of the implementation details they’re juggling in their short term memory. But if “slow” is the first word you think of that’s not very good. And if you look at the synonyms and antonyms you can solidify your understanding of the purpose of the function in your head. Maybe you meant thorough, or conservative. And maybe you meant to do one but actually did another. So now you can not just chose a name but revisit the intent. Plus you’re not polluting the namespace by recycling a jargon word that means something else in another part of the code, complicating refactoring and self discovery later on.

gorgoiler 2y ago

Hah, I swing the other way! If module foo had a function bar then my test is in module test_foo and the test is called test_bar. Nine times out of ten this is the only test, which is mostly there to ensure the code gets exercised in a sensible way and returns a thing, and ideally to document and enforce the contract of the function. What I absolutely agree with you on is that being able to describe this contract alongside the function itself is far more preferable. It’s not quite literate programming but tools like Python’s doctest offer a close approximation to interleaving discourse with machine readable implementation: def double(n: int) -> int: “””Increase by 100% >>> double(7) 14 “”” return 2 * n

hu3 2y ago
> If module foo had a function bar then my test is in module test_foo and the test is called test_bar. Same. This is a good 80/20 in my experience. Testing the happy paths is already very rewarding.

deleted 2y ago

[deleted]

misja111 2y ago

Thanks for the hint about Knuth's literate programming! I hadn't heard about it before but it immediately looks great. (For those of us who hadn't heard about it before either, here is a link: https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming) About your other point: I have experienced exactly the same. It just seems impossible to instill the belief into most developers that readable tests lead to faster solving of bugs. And by the way, it makes tests more maintainable as well, just like readable code makes the code more maintainable anywhere else.

yesbabyyes 2y ago

As a fan of literate programming, I hope this could be a tool in the box for Node.js developers: Testy is basically doctests for Node.js, building off JSDoc's @examples stanza. I would be honored by anyone checking it out: https://github.com/linus/testy https://github.com/linus/testy

paxcoder 2y ago
[dead]

ojkelly 2y ago

Test names are one of those things that are painful because it’s obvious to you as you write it, but there’s an extra hassle to switch gears in your head to describe what the contents of the test is doing. It is really valuable when they are named well. I’ve found this is where LLM can be quite useful, they’re pretty good at summarising. Someday soon I think we’ll see a language server that checks if comments still match what they’re documenting. The same for tests being named accurately.

pydry 2y ago
I've never seen this as a problem. If you're doing TDD and you have a scenario in mind, you describe that scenario in the name of the test. If you're writing the test after then yeah, maybe it's hard, but that's one of the many reasons why it's probably better to write the test before and align it with the actual feature or bugfix you're intending to implement.
- mewpmewp2 2y ago
  Maybe also why TDD is hard for me because I only truly start to think or visualize when I'm writing the actual code. I don't know if it's ADHD or what it is, but writing requirements, tests before hand, is just not my forte. It's like I only get dopamine from when I build something and everything else feels frustrating.
  - crazygringo 2y ago
    I used to be like that sometimes. Then I started realizing I'd get the function 90% complete and discover an edge case and have to start over in a way that could handle the edge case. Sometimes this could happen twice. Documenting your requirements by writing the tests in advance is of course painful because it forces you to think more upfront about the edge cases in advance. But that's precisely why it saves time in the long run, because then it makes it a lot more likely you can write the function correctly from the start.

gus_leonel 2y ago

Test names should be sentences: https://bitfieldconsulting.com/posts/test-names https://bitfieldconsulting.com/posts/test-names

nuancebydefault 2y ago
In fact that is not very hard to do and provides a great advantage!
wnmurphy 2y ago
100%. Test names should include the word "should" and "when". Then you get a description of the expected behavior.
wubrr 2y ago
Shallow/meh, article. Demonstrates complete lack of familiarity with many popular testing frameworks/approaches, and proposes a subpar solutions for problems that have already been solved in superior ways. Your test description/documentation should be sentences, but there is absolutely zero reason to try to encode that into the name of your test function. Not to mention this article then suggests using another tool to decode this function name into a proper sentence for reporting... ok now you completely lost the ability to ctrl+f and jump to the function... terrible advice all around. Why not just use a testing framework that actually supports free-form sentence descriptions/documentation for your tests?
- bunderbunder 2y ago
  If my unit testing framework supports free-form sentence descriptions, I'll use it. But I won't use that feature as a wedge issue. It doesn't bother me all that much to have test functions with names like `test_transaction_fails_if_insufficient_funds_are_available()`. Other features of the test framework might have a much bigger impact on my developer experience.
  - wubrr 2y ago
    Pretty much every major language/framework now supports free-form test names/descriptions, including JUnit, which is referenced in the article ^ (again, highlighting the author's ignorance). Just because something doesn't bother you personally doesn't mean it's a good thing to follow, especially when its clearly inferior to other options. > It doesn't bother me all that much to have test functions with names like `test_transaction_fails_if_insufficient_funds_are_available() I mean, that's one example where you have one outcome based on one parameter/state. Expand this to a 2-field outcome based on 3 state conditions/parameters and now you have a 100-character long function name.

paxcoder 2y ago

[dead]

macspoofing 2y ago

>Getting all your teammates to quit giving all their tests names like "testTheThing" is darn near impossible. You can do better than "testTheThing". Have your team (or a working group composed of your team, if your team is too big) put together a set of guidelines on naming conventions for unit test methods. Have your team agree to these conventions (assumption is that the working group would have consulted with rest of team and incorporated their feedback). Then make that part of the code review checklist (so you aren't the one that is actually enforcing the policy). Do spot checks for the first little while, or empower some individuals to be responsible for that - if you really want to. Do a retrospective after a month or 2 months to see how everyone is doing and see how successful this initiative was.

crabbone 2y ago

Bad work practices create bad social dynamics. If someone on the team isn't pulling their weight by being lazy, I don't see a reason to like that person if I'm their team member.

nzach 2y ago

>Getting all your teammates to quit giving all their tests names like "testTheThing" is darn near impossible. Sometimes people are pretty bad a coming up new names, but selecting a good name given some options generally isn't a big problem. So maybe we should create a kind o LLM linter for this situation ? The prompt could be along the lines: "Given this function: <FUNCTION> This unit test: <UNIT TEST> And these naming considerations: <NAMING GUIDE> Is the current test name a good option? What would be some better options?" I did some quick testing and it seems work to reasonably well. It doesn't create anything mind-blowing but at least it seems to provide some consistent options.

nzach 2y ago
Here is a really bad POC for golang tests, if anyone is interested: https://github.com/nzachow/lmlinter https://github.com/nzachow/lmlinter Right now it just prints the prompt in the terminal.

flerchin 2y ago

You know what they say: Naming things is one of the 2 hardest problems in computer science. The other one being cache invalidation and off by one errors.

SAI_Peregrinus 2y ago
Or the async version There are three hard problems in computer science: 1) Naming things 2) Cachoncurr3)e invalidation ency 4) Off-by-one errors
- Jerrrrrrry 2y ago
  this is incredibly unnerving of a comment, thank you.

TheSoftwareGuy 2y ago

This is one area where a BDD style framework like catch2[0] really shines, IMO. The way tests are written in this style naturally lends itself to self-documenting each branch [0]: https://github.com/catchorg/Catch2 https://github.com/catchorg/Catch2

nuancebydefault 2y ago

I used to be the weenie who always said we need to define nomenclature before things get silly names (hence very very early to prevent those to become the norm for legacy reasons) and use proper naming for everything, such that code would read like a novel (yes that is a stretch). But indeed it tended to lead to frustrating social dynamics in stead of happy romcom scripts. So I gave up on most of it. That said, my opinion about test code is, it exists to find bugs or steer away from regression. API descriptions, together with a design with some graphs, should be formal and clear enough to understand code usage. I don't want to figure out the usage of fwrite() by going through its elaborate test suite.

wryoak 2y ago

I encourage my teams to include the project tracker ticket name of the requirement or bug fix in the name. Eg, “XYZ12” -> fn { … } // test for value always being positive Of course some test libraries make this approach difficult.