The best practices for naming tests

Imagine a huge project where each developer writes tests descriptions in their own way. It will be complete mess. That's why it's a good idea to adopt some rules and stick to them from the beginning of the project

Some consistent rules

Take a look at the following example:

describe("Pizza meets standards when", () => { 👍 it("size is between 30-40cm", () => {}); 👍 it("cake is brown", () => {}); 👍 it("cheese is melted", () => {}); 👍 it("cake is warm", () => {}); 👍 it("plate is clean", () => {}); 👍 describe("plate size is equal to", () => { it('30cm', () => {}); 👍 it('40cm', () => {}); 👍 }) });

We can read the following descriptions as one sentence: or (look at nested describe block). Thanks to that we are able to read tests as documentation and immediately understand the testing case.

We used the following rules to build the above cases:

Consistency is very important! If you take care of such things from the beginning you will make your project much easier to understand and more enjoyable to work with.

If you enjoyed it, be sure to visit us on where we regularly upload content from programming.