goldbergyoni/javascript-testing-best-practices

📗🌐 🚢 Comprehensive and exhaustive JavaScript & Node.js testing best practices (July 2023)

javascript-testing-best-practices's Issues

Credits to contributors

@js-kyle

Here's an updated list of people who deserve a credit on our home page

@stdavis
@AdrienRedon
@NoriSte
@yjoer
@jhonnymoreira
@Germanika
@AbdelrahmanHafez
@ruxandrafed
@jacklee814
@aloyr
@huhgawz
@battaile
@rubicker
@haakonmb
@jaimemendozadev
@camerondunford
@shadowspawn
@aurelijusrozenas
@aaronshivers
@tomanagle
@yvesyao
@Userbit

Working on v2 of this guide, ideas for improvements?

I'm enhancing the content now, writing more best practices and polishing existing content.

Have improvements ideas? Let me know 🙏🦄

Shield/Badges with wrong title or in wrong place

I have already made a PR on this #69 but i suspect there are more Badges with wrong titles.
Also i think some of the badges are in the wrong code examples.
For example in the pratice 3.4 the first example has React and React Testing Library Badges but it is actually a Cypher example.

I would fix it but i'm not sure which ones are correct or not. Maybe someone with more experience should take a look.

Numbering of subpoints

Description

Numbering of subpoints needs fixes. At this moment - missing 1.9. For fix: 2.12 & 2.13.

Screenshots

1.9

2.12-2.13

Best wishes,

Persian(Farsi) Translation

hi
I would like to translate it into Persian/Farsi.

thank you for creating this great repo!

[3.2] Is data-test-id a good idea?

I have seen this in cypress's documents that suggest to use data-test-id attribute to locate specific element. This can make test more stronger that survive changes like html structures and css names. However, in practice we found it is hard to avoid name conflicts in big project, and a lot of 3rd party ui components cannot add this attribute.

What we do is to use user aware information to locate element. In my opinion, if the feature requirement has changed, then the tests should change as well. For e2e testing, using data-test-id violates the principle 1.4 "Stick to black-box testing".

So we use text to locate elements. If the element has no text, like icon button, as far as it is Interactable, it should have some a11y information for visual disability users. And our test framework is another user with such disability. Therefore, aria attributes are used to locate almost every elements that should be cared in our test cases. I think this is a better practice compared to data-test-id. And we use Google's Semantic Locators to achieve this.

Make release

Please make release from time to time to have notification for those who use Github's feature "Watch Release only"

Use Mocha's context (alias for describe)

I like Mocha's context alias for describe. Consider the following example (from 1.1):

//1. unit under test
describe('Products Service', function() {
  describe('Add new product', function() {
    //2. scenario and 3. expectation
    it('When no price is specified, then the product status is pending approval', ()=> {
      const newProduct = new ProductService().add(...);
      expect(newProduct.status).to.equal('pendingApproval');
    });
  });
});

It could be rewritten:

//1. unit under test
describe('Products Service', () => {
  // 2. specific capability
  describe('Add new product',() => {
    // 3. scenario
    context('When no price is specified', () => {
      // 4. expectation
      it('Should have product status as pending approval', () => {
        const newProduct = new ProductService().add(...);
        expect(newProduct.status).to.equal('pendingApproval');
      });
    });
  });
});

Call for more translations

Hey hey,

I currently work on v2 of this guide, it will contain a few enhancements to modernize it. I think it could be awesome if we outreach more audience by speaking their mother-tongue language.

If you'd like to localize i - I'll be happy to assist by branching, cloning, finding reviewers and seeking colleagues who might help. Goes without saying, that the translated version will have your name boldly on top.

Let me know if this desirable 🙏

@ngthuongdoan @eskape @acebo @Rookiebutgood @YA21 @YukiOta @mbiesiad @contributorpw @mattjin @grafiktr @songe @abderrahmaneMustapha @nphan03

French Translation

Hello I'm a young junior web french developer and I'm very interested in testing right now. Therefore I propose if you wish to participate in the French translation if you allow me?

Suggestion of some little markup rules for deep conformity in the context of languages

Hi! I'm an amateur translator. I love markdown. I also like the count lines of any translated documents to match. Ever.

I would like to suggest some guidelines to improve our markdown translation practice. Related #161

1. Do not break the paragraph on a new line. All lines are endless. Line length is endless. This means that a thought within a paragraph will always be within a paragraph. It is enough for us to know its line number.
2. Do not add more than one blank line. There may be a blank line between paragraphs. This is normal and often convenient. Many blank lines confuse the translator. Sometimes the thought is created that something is lost here.
3. Try to use punctuation that are appropriate for your language. It helps others understand you in the final language. For example in my language almost no apostles or single quotation marks are used.
4. Use a linter on your side. There are many linters we cannot synchronize them all. I'm using markdownlint. I just add .markdownlint.json to .git/info/exclude

Russian translation

Hello, Yoni! Thank you for your great work!
I would like to make Russian translation of your book.
Could you give me your blessing for it?

P.S. Here is repository for it: https://github.com/Rookiebutgood/javascript-testing-best-practices

New BP: Avoid coupling between tests, each fail and succeed regardless of the other

• Ideas and keywords: Fragile, domino cards, execution order, random order, create the state in the arrange phase (not in the previous test), avoid globals, repeat yourself*

Vietnamese Translation

Just came across this amazing document, I'll translate it into Vietnamese ASAP 👌👌👌

Japanese 🇯🇵 Translation

Hi, I just came across this repo and would love to contribute to the Japanese translation!

---

EDIT: My friendly co-worker @kawamataryo kindly volunteered to work on the translation together! 🎉
Right now, we are working on a forked branch on my account here: https://github.com/yuichkun/javascript-testing-best-practices/blob/master/readme-jp.md

Progress

• Introduction
• Section 0
• Section 1
  • 1.1
  • 1.2
  • 1.3
  • 1.4
  • 1.5
  • 1.6
  • 1.7
  • 1.8
  • 1.9
  • 1.10
  • 1.11
  • 1.12
  • 1.13
• Section 2
  • 2.1
  • 2.2
  • 2.3
  • 2.4
  • 2.5
  • 2.6
  • 2.7
• Section 3
  • 3.1
  • 3.2
  • 3.3
  • 3.4
  • 3.5
  • 3.6
  • 3.7
  • 3.8
  • 3.9
  • 3.10
  • 3.11
• Section 4
  • 4.1
  • 4.2
  • 4.3
  • 4.4
• Section 5
  • 5.1
  • 5.2
  • 5.3
  • 5.4
  • 5.5
  • 5.6
  • 5.7
  • 5.8
  • 5.9
• Team

How to add contributor to list?

@js-kyle Layman question - when I approve John Doe's PR, will he be added automatically to the list or should I do anything manual?

edupro-social-links-widget-1 needs fix

Description

At this moment content of edupro-social-links-widget-1 works incorrect. See screenshots and details below.
First issue - there is an icon of Google+ (inactive platform since ~2019). Second issue - icons/links are not working correct now.

Repro steps

1. Go to: https://testjavascript.com/
2. Scroll down, take a look at edupro-social-links-widget-1 elements. Click on the icons
3. See the issue

Screenshots

Google+ icon (inactive platform)

Link for fix - FB example

Link for fix - Twitter example

Additional info

After clicking, it redirects to the website: https://testjavascript.com/

PS. Small suggestion from my side - I think it would be great to open the site (correct site) in new tab (target="_blank") instead of the same tab.

Best wishes,

Link to Spanish translations is missed in READMe files

Hi! I notice that Spanish translation is already merged but the README file doesn't contains the link to that translation.

PR created

Hope it helps

🎓 Preview my Node.js testing course

[Edit: The registration is closed, thanks for the previewers who joined.

I'll update here once the course is ready]

📢 I'm working on a comprehensive course about modern Node.js testing. It will contain more than 10 hours about the basics and also super-advanced topics like Microservice testing, testing with DB, contract testing and many others.

✅ To ensure the content quality is high - the lessons will be shared first with a closed group of programmers. Based on the feedback, the content will be then refined.

👥 Would you like to join the preview group, no costs, and get access to all the lessons before they get published? If yes, just fill the short form here (~3min) and I'll start sharing content very soon

Section 1.1 example code should check for true, not false

The second example in section 1.1 says:

expect(result.approved).to.be.false;

It should be:

expect(result.approved).to.be.true;

(I'm guessing you made it false so you could simulate the error output in the next picture.)

das

2nd example of bullet 3.10 is missing

BTW, I'm working on translating this readme to Chinese Simplified, and will be done today :]

Spanish translation

Great job! I think it is the most clear and comprehensive guide I ever read.

I think a Spanish translation could help some of my colleagues that don’t have English skills.

Can I help you doing the Spanish translation?

THANKS FOR MAKING THIS 🔥

Hi @goldbergyoni,

Would really like to say thanks for making this resource! Every other resource for learning how to write tests really sucks!

What you've made on the other hand is a real game changer! 🔨

Portuguese (BR) Translation

Hi! Thanks for all content here!

I can start a pt-br translation?
What's the best first step?

Backend testing

For example, consider an IoT application that ingests many events into a message-bus like Kafka/RabbitMQ, which then flow into some data-warehouse and are eventually queried by some analytics UI. Should we really spend 50% of our testing budget on writing unit tests for an application that is integration-centric and has almost no logic?

There's almost no unit testing here. Write a tiny bit of integration and e2e if its critical, if not forget it.. This still follows the pyramid. Its relative to amount of unit test (domain model/business logic) code required. You want ~100% of the behavior of business logic (unit) according to the pyramid. In this case 100% of zero is zero.

ref

Section 5.6 has wrong text for Do and Otherwise

Great coverage and content, thanks!

I noticed section 5.6 incorrectly starts with the first paragraph from section 5.5 and then the intended text appears in the "otherwise":

✅ Do: Licensing and plagiarism issues are probably not your main concern right now, but why not tick this box as well in 10 minutes? A bunch of npm packages like license check and plagiarism check (commercial with free plan) can be easily baked into your CI pipeline and inspect for sorrows like dependencies with restrictive licenses or code that was copy-pasted from Stackoverflow and apparently violates some copyrights

❌ Otherwise: Even the most reputable dependencies such as Express have known vulnerabilities. This can get easily tamed using community tools such as npm audit, or commercial tools like snyk (offer also a free community version). Both can be invoked from your CI on every build

Avoid mocks in favor of stubs and spies

Avoid mocks in favor of stubs and spies

Correct me if im wrong but i was reading this paper (Mocks Aren't Stubs) you provided about test doubles, and then i compared it to what you wrote.

In the paper they say the following :

Mock objects always use behavior verification, a stub can go either way. Meszaros refers to stubs that use behavior verification as a Test Spy. The difference is in how exactly the double runs and verifies and I'll leave that for you to explore on your own.

but what is written on your documentation is ( i think maybe i didn't understand what you said ) is not the same where mocks are pushed as they don't follow behavior verification and that stubs are fully designed for behavior verification but in reality they can go either way (stubs).

So can you please provide a clearer answer about that section because im kind of confused

das

Few small typos

Hi, few small typos to correct:
(first row - original, second - recommended version)

2.1
white*check_mark
white_check_mark

*_all
_all_

-*_ vs _

Cindy Sridharan suggests a rich testing portfolio in her amazing post ‘Testing Microservices—the sane way
(...) same (...)
-same vs sane

some fear. and fear will slow you down
(...) , and (...)
-not dot

Great job!
Best greetings

Polish translation

Hello. I would like to translate this repo to Polish.

Translate pt-Br

Can i translate this repo to pt-Br?

Cover image and link to medium article

Hi!
Thanks for awesome repo!

I arrived at this repo from the medium.com article. I realled loved the cover picture below.

I'm not a testing professional to decide if it's technically 100% correct diagram, but it's one of the most clear diagrams I've seen that shows the testing phases. Perhaps this could be included in Readme.md file?

Also perhaps the medium article link can also be added to somewhere in Readme.md file?

Image:

Translate it to arabic language 🇦🇪

I would like to translate it , I will open PR in this branch

Thanks for awesome guide

Can I translate this repo to ko-KR?

Awesome writing!

New BP: Copy the necessary details between tests

• Ideas and keywords: Tests as a standalone universe, should tell a short but complete story, can be cumbersome if copying huge JSON, can be vague when extracting out

How do you write testable code?

Not sure if that is out of the scope of this best practice guide. I, however, miss an integral part that explains how to write code that is easier to test in the first place.

That is only explained on the side in point 1.13 - other generic testing hygiene. This could be split into two or three points that specificially focus on the do's and don'ts to enable testing and how to structure such code.

This is my subjective view or recommendation I would put into the list:

Bad examples:

• Using global state can make testing a nightmare, when two tests attempt to access the same state at the same time.
• Mutability grants loopholes for impossible state

Good examples:

• Extract pure data handling and decision making to their own side-effect free function to promote easier testing
• Make options and behavior configurable (using dependency injection/rejection in function parameters/class constructor) to allow unit-testing.

In my experience, that goes hand in hand with benefits like more readable code, configurable behavior and options, focused functions. Some recommendation how to structure code or functions in a way that enables testing in the first place would be great.

What do you think?

Italian translation

Hi, I will take the duty to translate the whole repo in Italian

• Introduction
• Section 0
• Section 1
  • 1.1
  • 1.2
  • 1.3
  • 1.4
  • 1.5
  • 1.6
  • 1.7
  • 1.8
  • 1.9
  • 1.10
  • 1.11
  • 1.12
  • 1.13
• Section 2
  • 2.1
  • 2.2
  • 2.3
  • 2.4
  • 2.5
  • 2.6
  • 2.7
• Section 3
  • 3.1
  • 3.2
  • 3.3
  • 3.4
  • 3.5
  • 3.6
  • 3.7
  • 3.8
  • 3.9
  • 3.10
  • 3.11
• Section 4
  • 4.1
  • 4.2
  • 4.3
  • 4.4
• Section 5
  • 5.1
  • 5.2
  • 5.3
  • 5.4
  • 5.5
  • 5.6
  • 5.7
  • 5.8
  • 5.9
• Team

Translate to Ukrainian 🇺🇦

Hi here. Can i start translating your guides to ukrainian language ?

Do you have some recommendations or restrictions?

Ukrainian translation

Hey, guys. I would like to translate this guide into Ukrainian. How do you feel about it?

5.6 Constantly inspect for vulnerable dependencies

Certificate expirations are very common and when your production site are down all the weekend becase the certificates expired on Fridays night, that is very annoying.

I think that it's a good idea to add a test that advise you X days before the certificates expires using a tool like https://www.npmjs.com/package/ssl-checker.

Regards!

Indonesian Translation

I want to translate the English Javascript Testing Best Practices version to the Indonesian language, may I?

Dutch translation

Hi! Thanks for working on this. It helped me a lot.
I would like to give back some love and help out with a dutch translation.
What is the best way to start?

Section 1.9 and 2.7 are duplicates

The sections Avoid global test fixtures and seeds, add data per-test is present twice in 1.9 and 2.7

Javascript

Add Kyle to contributors

@js-kyle Can you PR your name in the contributors?

Thai Translation 🇹🇭

This is so awesome!! I have learned a lot from this.
I'm willing to translate it to Thai. Could you allow me? 🇹🇭 🇹🇭 🇹🇭

Turkish translation

Thank you for these great documents. Every word of it is really what the way 👏 Doing It Right.

And, i would really be pleased to read them in Turkish language too. I know many many much developers who even don't know what are tests. To help them understand the concept easier, please let me try to translate it.

PostgreSQL docker container optimization

Hello,
Thanks for the amazing guide!

I remember attending one of your talks about this guide, and you had a section with several configurations to optimize a PostgreSQL docker container, resulting in a significant reduction of tests runtime.

I couldn't find it here, is it available somewhere?

Turkish Translation

I just started translating this beautiful repo to Turkish.

---

Progress

• Introduction
• Section 0
• Section 1
  • 1.1
  • 1.2
  • 1.3
  • 1.4
  • 1.5
  • 1.6
  • 1.7
  • 1.8
  • 1.9
  • 1.10
  • 1.11
  • 1.12
  • 1.13
• Section 2
  • 2.1
  • 2.2
  • 2.3
  • 2.4
  • 2.5
  • 2.6
  • 2.7
• Section 3
  • 3.1
  • 3.2
  • 3.3
  • 3.4
  • 3.5
  • 3.6
  • 3.7
  • 3.8
  • 3.9
  • 3.10
  • 3.11
• Section 4
  • 4.1
  • 4.2
  • 4.3
  • 4.4
• Section 5
  • 5.1
  • 5.2
  • 5.3
  • 5.4
  • 5.5
  • 5.6
  • 5.7
  • 5.8
  • 5.9
• Team