11–20 of 28 posts
This is not end2end testing but, rather, component testing (or, possibly, contract testing if you took it a few steps further). In our stack, we refer to this as a post-build component test. https://martinfowler.com/articles/microservice-testing/#test...
This is not end2end testing but, rather, component testing (or, possibly, contract testing if you took it a few steps further). In our stack, we refer to this as a post-build component test. https://martinfowler.com/articles/microservice-testing/#test...
I think tying this to snapshots of application states ( https://dotmesh.com/ ) would be incredible for development throughput. When you have tons of data you can't be recreating it every time you run through your test suite. Anyone on HN currently doing this?
I would go with `nock` rather than spinning up a mock server: https://github.com/nock/nock
Earlier quoted context omitted.
Testing an HTTP API involves running the server, and running a client against that. Postman, insomnia, and Milkman are REST clients. I haven't tried it, but I think it'd be quite awkward to get a server setup from Postman. I think it would at least involve calls to external programs to start a server, or to run against an already running server. The more apples-to-apples comparison would be using Postman vs the chai…
>Testing an HTTP API involves running the server, and running a client against that. That's exactly what tools like Postman are used for. How are you doing any testing during the development process if you're not hosting your web API even locally? >I haven't tried it, but I think it'd be quite awkward to get a server setup from Postman There's no need to as I mentioned that you're going to be hosting it somewhere dur…
You will probably host 1 version which is infrastructure heavy and not very flexible. Take 10 developers working on the API. They all need to test their changes. Automatically if possible. Hosting external elements like the database and others is a pain eased by Docker.
This is not end2end testing but, rather, component testing (or, possibly, contract testing if you took it a few steps further). In our stack, we refer to this as a post-build component test. https://martinfowler.com/articles/microservice-testing/#test...
I don't understand this distinction. Is the reason that they are not testing the frontend itself? Would it be if they were only responsible for the API? Can't you end-to-end test an API?
All you should care about in an API testing is its specification correctness. Whats below should be tested by component tests or even units.
This approach more or less already has a concensus in api world. Im surprised there are still ppl doing e2es.
What's the benefit of this over tools that you're likely already using to build an API, such as Postman, insomnia or Milkman?
Testing an HTTP API involves running the server, and running a client against that. Postman, insomnia, and Milkman are REST clients. I haven't tried it, but I think it'd be quite awkward to get a server setup from Postman. I think it would at least involve calls to external programs to start a server, or to run against an already running server. The more apples-to-apples comparison would be using Postman vs the chai…
This is one of the best usecases for docker -- testing your system by spinning it up as it would be in production, with throwaway versions of the dependencies (the more realistic you can get them the better) is a fantastic way to test the overall system. I'm surprised anyone is still not doing this. The most useful tests are the ones that test a customer's flows -- who cares if some function in your backend code does…
I would argue you need both. Without that unit test you might find it difficult to account for or track down that particular edge case. Plus a test like that takes about 5 minutes to write.
The application has been written so you can plug in a local file system instead of S3 which again, is fantastic for throwaway tests. It can also catch emails that would be sent and verify the HTML content.
My rule is to not rely on any third part service for the tests.
While I am in favor of a Dockerized solution, and have used it extensively, the reasoning above is not entirely correct. You can Mock without the application noticing it in different ways, the simplest being using of a separate process running the Mock logic.
The befit of Docker is the same as in other contexts- you get a packed versioned solution that is easy to deploy and manage