Update unit test naming guidelines

[NicolasMassart]

Test Naming Guidelines Update

Updates our test naming conventions to improve clarity and maintainability of our test suite.

Key Changes

• Established clear guidelines for naming unit tests
• Added examples of good and bad practices
• Introduced principles for more descriptive and concise test names

---

Note

Low Risk
Documentation-only changes to contributor guidelines; no runtime, security, or application code is affected.

Overview
Updates docs/testing/unit-testing.md with clearer, more prescriptive guidance on how to name and structure unit tests, plus editorial tightening across the rest of the page.

The it description section is the main addition: eight numbered rules (present-tense verbs, outcome-focused wording, no filler like "should", avoid implementation details, etc.) and many new 🚫/✅ example pairs (tokens, redirects, errors, vague names). Snapshot tests now recommend names like matches rendered snapshot instead of should renders correctly, with complete example blocks.

Other sections are largely reworded for brevity (Jest intro, describe grouping, four-phase tests, isolation, beforeEach vs helpers, mocks, snapshots). Minor structural tweaks include bullet lists for private-code types, dropping the 💡 prefix on one heading, and removing one "Read more" link under test-as-specification.

^{Reviewed by Cursor Bugbot for commit dfdcb07. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Copilot]

Pull Request Overview

This PR updates our unit test naming guidelines to improve clarity and maintainability of our test suite.

• Added a structured set of instructions for naming tests using active verbs.
• Included new examples of both poor ("Don't") and good ("Do") naming practices.
• Provided an extended list of considerations to ensure test names are descriptive and concise.

Comments suppressed due to low confidence (1)

docs/testing/unit-testing.md:125

• [nitpick] The test name in this example includes the 'should' prefix even though the guidelines recommend avoiding it. Consider revising the test name to remove the 'should' prefix and focus directly on the behavior.

it('should successfully add token when address is valid and decimals are set and symbol exists', () => {

[mcmire]

Sorry this has been open for so long, I just realized I already reviewed this a while back but I forgot about this 🤦🏻

Thank you for this! As the original author of this guide, I fully admit I have a habit of using too many words. So I appreciate these changes. I had some comments/suggestions below, but they are all minor.

[mcmire]

Thanks for the discussion @NicolasMassart. Again I appreciate your attempts to make this more understandable and thanks for your patience. I think we are close on this.

[mcmire]

"a test ... when running alone" sounds like the test is running itself, hence the suggestion.

I see what you mean about "whether". What do you think about this instead:

Suggested change

	A test must pass when running alone or with other tests (in any order).
	A test must always pass. Running a test by itself or with a group of other tests must not change the result.

[mcmire]

Okay, good callout. Perhaps we could stick a "The" at the front then?

Suggested change

	Ways to keep tests isolated:
	The next sections suggest ways to keep tests isolated.

[mcmire]

To provide more details on this suggestion:

• It seems that we are telling the reader about a concept and then directing them to follow some instructions. As a reader the transition was not as smooth as I had hoped. By using the word "you" I thought this paragraph flowed a bit more smoothly with the previous one.
• We say "this makes it easy to undo later", but is the "it" in this sentence meant to refer to the mock function created or the global? My thought is that the thing we are undoing is the mock function. But if you disagree (or the wording you suggested is understandable well enough) we can keep the language as-is.
• I don't expect people to read this section all the way through so I thought we could remove "(Combine this with...)".

[mcmire]

I made this suggestion because I wanted to start this sentence with "If you want to..." in order to match the suggestion I made above. It also felt like we were missing instructions for the reader.

[mcmire]

I made this suggestion because it pairs with the next suggestion. Together it says:

"Take this code for example: . This code behaves exactly the same as though ..."

But if you see these sentences as separate, here is another attempt:

Suggested change

	For example, you might write this code:
	The following example defines a couple of private methods:

[mcmire]

I made this suggestion to pair with the previous suggestion (I am assuming that the reader has read the example above). But if you don't like the use of "this" (which I admit could be ambiguous), or if you think this sentence should stand alone, then here is another attempt:

Suggested change

	Consumers (and your tests) can only see the public interface, which behaves as if the private methods were inlined:
	Since consumers (and tests) can only see the public interface, the example above behaves as if private methods and properties were inlined:

[mcmire]

Another attempt, which is simpler:

Suggested change

	Therefore, test the public `stop` method by verifying all the behaviors that result from calling it, including the effects of the private methods:
	A test suite for this class might look like the following:

[mcmire]

I made this suggestion because I thought it was shorter. I also thought we didn't need to mention the module template; it is enough to follow these instructions.

[mcmire]

Thanks for the changes! LGTM.