Nodebestpractices: Extending testing best practices

[antoniq]

Hi there,

Together with @janis91 we have been working on a detailed overview of Node.js Testing best practices. We have published them in a blogpost https://blog.novatec-gmbh.de/modern-microservice-testing-concept-real-world-example/ and we provide a showcase project in github https://github.com/nt-ca-aqe/blog-microservices-testing-nodejs-typescript. Would that be interesting for you? I think especially for integration/component testing and contract testing, one does not find many examples.

Let us know!

Cheers,
Antoniya

[goldbergyoni]

@antoniq @janis91

Welcome.

This is very interesting. And very important. I added your post to my learning queue and will read soon. There are also some other important JS testing type that are not covered, also have some post waiting for finalization for many time (e.g. property based testing, chaos testing, etc)

Would you be able to format some of the content as bullets in our testing section?

[antoniq]

Hi @i0natan ,

Sure, let us know once you have read the blogpost content. We have followed the testing types defined in the modern Agile Testing Pyramid.

Cheers,
Antoniya

[goldbergyoni]

@antoniq, sure thing, plan to do it over the weekend

[goldbergyoni]

@antoniq @janis91

Took some time but finally found the time, read the article and enjoyed it. See below few remarks and a description of how we typically collaborate with writters.

Thoughts that pop to my mind during the read

1. In the era of lean testing, is there a compelling reason for both component and API testing? doing the later will achieve more or less the same results as the former
2. The case name looks a bit too technical to me, why mention the implementation ('promise should return') within the test name? should you change the implementation, e.g. move to async/await, would you need to change all your test names?
3. In the same realm as bullet 1', is there still a good reason to have integration testing and not just go straight to full component testing? e.g. why test the service + the db instead of testing the whole at once (api + service + db)?
4. The reason why Nock wasn't used is not fully explained, also Sinon is doing magical-nasty things, Mocks are like federal agents - unlike plain citizens they have a special license to kill... :]
5. The diagrams are beautiful, how did you craft them?

Our typical topical collaboration model
We might collaborate the same way we craft the security best practices section: we write ~20 comprehensive bullets with examples and quotes, usually this takes some time and investment, then we publish them as a medium.com article that links to this repo.

Benefits to us: (1) We learn, research, dive and write about testing. (2) Our articles usually gain mass traction (our latest article was 2nd most read node article on medium in July + featured article of Node weekly, etc) - we get a nice outreach and impact

Thoughts?

[antoniq]

Hi @i0natan ,

Thank you for taking your time to have a look! We will try to answer your questions:

1. As explained in the blogpost, it is recommened doing both. Integration testing focuses on the interaction with only one external component. Furthermore, scenario selection plays a key role - one does not need to test everything once again in the component test.
2. Regarding naming - it depends on the test target group. In our example, it is closer to the technical level. In case of target for people that are closer to the business - a tool like Cucumber can be integrated on top that will provide better readibility.
3. See 1.
4. Sinon is used for the unit tests, Nock was researched as a service simulator alternative. As mentioned, we did not find tool that fits our project needs.
5. It is this tool: https://sketch.io/sketchpad/

Regarding collaboration - your suggestion sounds very interesting.
Currently, we cannot say however how much time we can invest and when. Feel free to start. It could be that in 2-3 month we have more time to collaborate on the practices.

Cheers,
Antoniya and Janis

[goldbergyoni]

@antoniq

"Integration testing focuses on the interaction with only one external component. Furthermore, scenario selection plays a key role - one does not need to test everything once again in the component test"

Can you provide a concurrent and real-world example where this might worth the effort?

[antoniq]

Hi @i0natan ,

I am back from vacation and have time now to look at your question. I am not sure that I get your question completely - is it about the diff between integration and component testing?

[goldbergyoni]

@antoniq Yeah, my question should be clarified. But first, appreciate if you can clarify the following:

Integration testing means different things, Fowler for example, defines 3 types of them:

1. Testing microservice A who collaborate with B&C, we use the real B&C during the test
2. Testing microservice A who collaborate with B&C, we stub B&C
3. We test few components/layers of Microservice A

To which of the above options did you post refer?

[antoniq]

In connection to the article, we are using Narrow integration testing (2). Component testing covers more paths, but still does not use real running services.

[goldbergyoni]

@antoniq Do you see any compelling reason to use narrow integration testing (e.g. 2 layers/classes under test) instead of a component test (the entire flow)?

My view is - if you already pay the integration price (setup an environment which includes DB), then go all the way and check the component * behavior, from the perspective of the *user/client, by simulating native system flows without mocking anything but external services. As a bonus coverage will also get higher. Integration test on the other end, will force to simulate some artificial scenario (e.g. test two layers) and demand more effort for less value

[stale[bot]]

Hello there! 👋
This issue has gone silent. Eerily silent. ⏳
We currently close issues after 100 days of inactivity. It has been 90 days since the last update here.
If needed, you can keep it open by replying here.
Thanks for being a part of the Node.js Best Practices community! 💚