I prefer that the test name doesn’t say “should”. Instead, I like when it states the expected behaviour as though it was a fact.<p>“Should” to me is too weak.<p>No, it’s not just “should”. It does. And if it doesn’t then either the implementation is broken, or the test is bad.<p>“Should” has connotations for me of something that we want but which we don’t require.<p>Therefore, I don’t use the word “should” in my test names.<p>Instead of “should have length 256”, I say “has length 256”.
Nothing in this article makes sense to me. What is this, Hungarian notation for tests?<p>What if a test is testing that something shouldn’t happen? Apostrophes aren’t even legal function names in most languages. (/s)<p>> If the only output of a failing test is just a binary value like “FAIL”, that test is only giving one bit of information to the developer.<p>Well that aaaand<p>> A good test framework will also print the test name and a call stack.<p>Ok so more than one bit of information, it literally tells you the line number and filename of the failed test so you can go look at it. But yeah maybe bad developer didn’t put any comments in the test and the code isn’t obvious but sure they’re gonna name the test using a magic template.<p>> For example, they could point out that “should replace children when updating instance”<p>So in Go we would have:<p><pre><code> func TestShouldReplaceChildrenWhenUpdatingInstance(t *testing.T) { … }
</code></pre>
Argh this nonsense cargo culting just does my head in and I should go to sleep.
Strange, RSpec seems to go in the opposite direction, used to be<p><pre><code> it 'should increment the counter' do ...
</code></pre>
but now the active voice preferred<p><pre><code> it 'increments the counter' do ...
</code></pre>
I much prefer the latter.
Oh no, please not again... In 2021 we had some of our workers do courses where this was said. The effect was that many tests with really bad names where just renamed from testXXX to shouldXXX. It took a very long time to get those workers to write meaningful names and get rid of this should in the beginning (our framework recognizes tests by a name starting with test. The renamed tests have not been executed since the renaming).
Roy osherove's naming convention served me well over the years:<p>UnitOfWork_StateUnderTest_ExpectedBehavior<p><a href="https://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html" rel="nofollow">https://osherove.com/blog/2005/4/3/naming-standards-for-unit...</a>
...unless you use Apple's XCTest framework[0].<p>In that case, it's required that tests be prefixed with "test"[1].<p>[0] <a href="https://developer.apple.com/documentation/xctest" rel="nofollow">https://developer.apple.com/documentation/xctest</a><p>[1] <a href="https://developer.apple.com/documentation/xctest/defining_test_cases_and_test_methods" rel="nofollow">https://developer.apple.com/documentation/xctest/defining_te...</a>
> It removes redundancy, because the function name should already be in the call stack.<p>I agree, as long as there is 1 methot to test per file containing the tests. Otherwise, I put the tested method name first (if it's a unit test) and adhere to the pattern [method]_[should]_[condition]_[result], e.g. Divide_Int_ByZero_FailsWithException()
I thought "should" was a product of silly TDD, like my widget "should do this thing" and it doesn't yet because TDD, and then the developer would implement it.
My team use GIVEN X AND Y SHOULD Z<p>It works nicely with Jest as you can nest test suites indefinitely, so each GIVEN statement goes in a nested describe block, but it is verbose.
> Some frameworks require that test names are formatted in some special way, like starting with “test”, using snake case, camel case or other. I’m ignoring that part of the naming for brevity and to avoid focusing on a specific language.<p>I was thinking when I first saw this I thought this depends on what testing framework you’re using.<p>Basically, what this is saying is to follow the conventions of the testing framework?
Or just, y'know, write a brief comment. Testing is one of those places where the function name occurs exactly once, perhaps twice if the language doesn't have a nice testing framework. It doesn't need to be self-documenting.
The reason I was taught in a TDD classroom, is that starting with "should" lets your human brain start typing an easy to comprehend sentence.<p>It should be easy to write out requirments in simple terms.