Also, are you a fan of nesting test classes? Any opinions? Eg:
Class fibrulatatorTest {
Class highVoltages{
Void tooMuchWillNoOp() {}
Void maxVoltage() {}Realistically, many unit tests are far more complicated (in terms of business logic) than functions where names actually matter, like 'remove()', 'sort()', 'createCustomer()', etc. I've worked in several places where people aggressively pushed the 'encode test description in test name' BS, which invariably always leads to names like 'testThatCreatingACustomerFromSanctionedCountryFailsWithErrorX'. It's completely absurd.
> Also, are you a fan of nesting test classes? Any opinions?
It really depends on the framework you're using, but in general nesting of tests is a good thing, and helps with organizing your tests.
I think what you're focusing on is just syntax sugar. Those examples with the 'describe'/'it' pattern are just another way to provide names to test cases, and their goal is exactly the same. If you didn't have this syntactic support, you'd write the function names representing this.
It's exactly the same thing: documenting the test case in the code (so not a separate document), with its name.
The distinction between "comment" and "function name" becomes less relevant once one realizes a function's name is just another comment.
The goal may be the same/similar, but one of the approaches is clearly superior to the other for multiple reasons (as stated by me and other many times in this comment tree). Also, I don't think you quite understand what 'syntactic sugar' means.
> If you didn't have this syntactic support, you'd write the function names representing this.
It's not any kind of 'syntactic support'. Pretty much every modern language/testing framework supports adding free-form test descriptions and names through various means.
> It's exactly the same thing: documenting the test case in the code (so not a separate document), with its name.
It's very clearly not the same at all lmao. And a test name, test description, other useful test documentation/metadata are also not the same.
> The distinction between "comment" and "function name" becomes less relevant once one realizes a function's name is just another comment.
Huge differences between a function name, a comment, and an annotation. HUGE. Read the other comments in this thread to understand why. If you actually worked in an environment where stuffing a test description into a test name is the preferred approach for a non-trivial amount of time, you'd know that once you get past a certain level of complexity your test names explode to 100+ character monsters, if only to differentiate them from the other tests, testing a different combination of states/inputs and outputs, etc.
Good luck with that!
Tone is generally completely independent of good faith.
Go heal that ego and try again.
The uninviting tone discourages further discussion. I really appreciated where this convo was going until..
> Read the other comments in this thread to understand why.
This could be restated in a non aggressive way. Eg: 'Other comments go into more details why'
> If you actually worked in an environment
Presumptive statements like this are unhelpful. We need to remember we do not know the context and experiences of others. Usually better to root discussion from ones own experience and not to presume the others perspective.