Thanks! I'm always worried about not making sense because English not being my native language.
Usually, I found hidden coupling at the early stages of developing providers (in the sense of MySQL, RabbitMQ or a microservice) architecture to hide that accidental complexity. Like, the other day I was connecting a microservice to a legacy one that had a logical coupling (it wasn't so micro) and the provider class was reflecting that coupling.
For me, Integration Tests are a tool that ensures that the software being developed does what it says. It is important the part of "software being developed" anything outside it should be mocked. I usually code APIs (Postman is all the frontend I need :P) so, my Integration Tests are usually a bunch of HTTP calls with assertions for the replies.
I use NodeJs most of the time and use Nock and Supertest
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks! I'm always worried about not making sense because English not being my native language.
Usually, I found hidden coupling at the early stages of developing providers (in the sense of MySQL, RabbitMQ or a microservice) architecture to hide that accidental complexity. Like, the other day I was connecting a microservice to a legacy one that had a logical coupling (it wasn't so micro) and the provider class was reflecting that coupling.
For me, Integration Tests are a tool that ensures that the software being developed does what it says. It is important the part of "software being developed" anything outside it should be mocked. I usually code APIs (Postman is all the frontend I need :P) so, my Integration Tests are usually a bunch of HTTP calls with assertions for the replies.
I use NodeJs most of the time and use Nock and Supertest