3 ms·

> It removes redundancy If it’s at the start of every test it’s completely redundant.

by mnd999 4y ago

dgb23 4y ago
Splitting hairs. The valuable advice here is that a test function should be named to reflect what it is testing rather that the name of the function it calls. Depending on the test library you use, there’s already in built stuff for this. The prefix is not the point, but it might help to write better names for tests: - can handle negative input - cannot handle zero - should return a http error code Might be better than: - test calcultate negative - test calcultate zero - test handler http code
- mnd999 4y ago
  This is why arbitrary rules are bad. 2/3 of your examples there would fail code review because they don’t start with ‘should’. Sure you could rename them to ‘should not handle zero’ but is that better? I would argue not.
  - robertlagrant 4y ago
    Well. They're sometimes bad.
  - sowbug 4y ago
    Back when I was on a team that used it, I liked Doxygen because it would take your comment and drop it into a sentence, so if I provided "fluxes the capacitor", I'd see "TimeTravelingCar fluxes the capacitor." in the documentation. If I capitalized it, my documentation would have "TimeTravelingCar Fluxes the capacitor.", which looks wrong, so I learned not to capitalize. If I added punctuation at the end, it would read "TimeTravelingCar fluxes the capacitor..", so I learned not to do that. It was a nice way to learn implicit rules in an applied manner. (Sorry for the nonstandard punctuation, but it's necessary here.)
- dist1ll 4y ago
  There's a better way: get red of can or should, and just assert its truth. - handles_negative_input - handles_zero - returns_http_error_code
  - marcosdumay 4y ago
    Personally, I prefer to name them as code examples instead of as tests: - negative_input - zero_input - bad_request When you run the "bad_request" test, you should get an error code, but that's on the assert already.
  - MetaWhirledPeas 4y ago
    I don't think this necessarily goes against the author's point. I think encouraging "should" was just a means to an end.
- sorokod 4y ago
  It sounds like you disagree with the author of the blog who literally choose the title "Start test names with “should”"
  - MetaWhirledPeas 4y ago
    In the article itself, his justifications align with GP's.
- collinvandyck76 4y ago
  I will often use a concise test name, and drop a comment along side describing what the test is evaluating if it's not obvious. Works great, and I'm only constrained by my ability to write english. Will also admit that I was a big DSL fan back in the ruby heyday. Works great if it's only you on the project but requiring a whole team to be DSL domain experts for something like testing is asking quite a lot.

> It removes redundancy If it’s at the start of every test it’s completely redundant.

by mnd999 4y ago

> It removes redundancy If it’s at the start of every test it’s completely redundant.

Splitting hairs. The valuable advice here is that a test function should be named to reflect what it is testing rather that the name of the function it calls. Depending on the test library you use, there’s already in built stuff for this. The prefix is not the point, but it might help to write better names for tests: - can handle negative input - cannot handle zero - should return a http error code Might be better than: - test calcultate negative - test calcultate zero - test handler http code

mnd999 4y ago
This is why arbitrary rules are bad. 2/3 of your examples there would fail code review because they don’t start with ‘should’. Sure you could rename them to ‘should not handle zero’ but is that better? I would argue not.
- robertlagrant 4y ago
  Well. They're sometimes bad.
- sowbug 4y ago
  Back when I was on a team that used it, I liked Doxygen because it would take your comment and drop it into a sentence, so if I provided "fluxes the capacitor", I'd see "TimeTravelingCar fluxes the capacitor." in the documentation. If I capitalized it, my documentation would have "TimeTravelingCar Fluxes the capacitor.", which looks wrong, so I learned not to capitalize. If I added punctuation at the end, it would read "TimeTravelingCar fluxes the capacitor..", so I learned not to do that. It was a nice way to learn implicit rules in an applied manner. (Sorry for the nonstandard punctuation, but it's necessary here.)
dist1ll 4y ago
There's a better way: get red of can or should, and just assert its truth. - handles_negative_input - handles_zero - returns_http_error_code
- marcosdumay 4y ago
  Personally, I prefer to name them as code examples instead of as tests: - negative_input - zero_input - bad_request When you run the "bad_request" test, you should get an error code, but that's on the assert already.
- MetaWhirledPeas 4y ago
  I don't think this necessarily goes against the author's point. I think encouraging "should" was just a means to an end.
sorokod 4y ago
It sounds like you disagree with the author of the blog who literally choose the title "Start test names with “should”"
- MetaWhirledPeas 4y ago
  In the article itself, his justifications align with GP's.
collinvandyck76 4y ago
I will often use a concise test name, and drop a comment along side describing what the test is evaluating if it's not obvious. Works great, and I'm only constrained by my ability to write english. Will also admit that I was a big DSL fan back in the ruby heyday. Works great if it's only you on the project but requiring a whole team to be DSL domain experts for something like testing is asking quite a lot.