4 ms·

Some languages / test tools don’t enforce testNamesLikesThisThatLookStupidForTestDescriptions, and you can use proper strings, so you can just say meaningful re

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 2y 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.
- chriswarbo 2y ago
  The `describe`/`it` nesting pattern is quite common (I currently use it in Jest and HSpec); but it doesn't solve the social problem. It's common to see tests like: describe("foo", () => { describe("called with true", () => { it("returns 1", () => { assert(foo(someComplicatedThing, true) === 1) }) }) describe("called with false", () => { it("returns 12", () => { assert(foo(someOtherIndecipherableThing, false) === 12) }) }) }) It's the same problem as comments that repeat what the code says, rather than what it means, why it's being done that way, etc. It's more annoying in tests, since useless comments can just be deleted, whilst changing those tests would require discovering better names (i.e. investigating what it means, why it's being done that way, etc.). The latter is especially annoying when a new change causes such tests to fail. Tests with such names are essentially specifying the function's behaviour as "exactly what it did when first written", which is ignoring (a) that the code may have bugs and (b) that most codebases are in flux, as new features get added, things get refactored, etc. They elevate implementation details to the level of specification, which hinders progress and improvement.
  - yakshaving_jgt 2y ago
    At the end of the day, someone has to shoulder the burden of holding their colleagues to higher standards. I don’t think there’s a technical solution to this social problem.
    - chiph 2y ago
      This is part of the job of being a team lead or manager. You have a standard, you need to get people to follow it (or consequences..)
    - cle 2y ago
      It could also be a symptom of something else, like I’ve seen this happen when someone goes overboard on unit tests and they become so burdensome that other engineers just want to get it out of the way. They may not consciously realize it, but subconsciously they know that it’s BS and so they don’t mind BS names to just move on with actual productive work. Not saying it’s always the case, but it could be. Higher standards are not always better, they have diminishing returns.
      - mewpmewp2 2y ago
        It's all a spectrum of trade-offs with different people having different opinions. There could be some sort of formula to explain this better to determine how much effort to spend on tests vs features and product quality and importance of quality compared to that.
  - wubrr 2y ago
    Yeah, it doesn't solve the problem of low quality code/laziness, but it's a better tool/approach for documenting your tests than encoding the description/documentation into it's name. Encoding such information into the name makes about as much sense as encoding constraints into SQL column names.
wubrr 2y ago
Yup, I've not actually seen any tool that enforces these kinds of test names. But yeah, trying to encode test description/documentation into it's name is like one of the worst common ways of documenting your tests.

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

chriswarbo 2y ago
The `describe`/`it` nesting pattern is quite common (I currently use it in Jest and HSpec); but it doesn't solve the social problem. It's common to see tests like: describe("foo", () => { describe("called with true", () => { it("returns 1", () => { assert(foo(someComplicatedThing, true) === 1) }) }) describe("called with false", () => { it("returns 12", () => { assert(foo(someOtherIndecipherableThing, false) === 12) }) }) }) It's the same problem as comments that repeat what the code says, rather than what it means, why it's being done that way, etc. It's more annoying in tests, since useless comments can just be deleted, whilst changing those tests would require discovering better names (i.e. investigating what it means, why it's being done that way, etc.). The latter is especially annoying when a new change causes such tests to fail. Tests with such names are essentially specifying the function's behaviour as "exactly what it did when first written", which is ignoring (a) that the code may have bugs and (b) that most codebases are in flux, as new features get added, things get refactored, etc. They elevate implementation details to the level of specification, which hinders progress and improvement.
- yakshaving_jgt 2y ago
  At the end of the day, someone has to shoulder the burden of holding their colleagues to higher standards. I don’t think there’s a technical solution to this social problem.
  - chiph 2y ago
    This is part of the job of being a team lead or manager. You have a standard, you need to get people to follow it (or consequences..)
  - cle 2y ago
    It could also be a symptom of something else, like I’ve seen this happen when someone goes overboard on unit tests and they become so burdensome that other engineers just want to get it out of the way. They may not consciously realize it, but subconsciously they know that it’s BS and so they don’t mind BS names to just move on with actual productive work. Not saying it’s always the case, but it could be. Higher standards are not always better, they have diminishing returns.
    - mewpmewp2 2y ago
      It's all a spectrum of trade-offs with different people having different opinions. There could be some sort of formula to explain this better to determine how much effort to spend on tests vs features and product quality and importance of quality compared to that.
- wubrr 2y ago
  Yeah, it doesn't solve the problem of low quality code/laziness, but it's a better tool/approach for documenting your tests than encoding the description/documentation into it's name. Encoding such information into the name makes about as much sense as encoding constraints into SQL column names.

wubrr 2y ago

Yup, I've not actually seen any tool that enforces these kinds of test names. But yeah, trying to encode test description/documentation into it's name is like one of the worst common ways of documenting your tests.