Can someone explaine the proposed Dockerile ? I understand that they use multi stage builds, but I don't really get the point of doing something like
FROM dependencies AS runtime
COPY . .
API end to end testing with Docker
21–28 of 28 posts
Re: API end to end testing with Docker
#22Earlier 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…
For this reason I created https://www.apilope.com - you can trigger hosted API tests from your CI workflow as well.
Getting a warning on the latest Firefox; seems like the certificate is expired.
Re: API end to end testing with Docker
#23Earlier quoted context omitted.
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?
I would simply say that testing APIs with pacts is a better approach than e2e testing.. Overall e2e testing is something you want to get rid off, cos development loop with it is too long and not modular. 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 surpris…
> Im surprised there are still ppl doing e2es.
You're surprised that there are people actually testing that things work after integration, interacting with the system as a user would?
I'm surprised there are still people who don't.
Re: API end to end testing with Docker
#24Earlier quoted context omitted.
>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…
> There's no need to as I mentioned that you're going to be hosting it somewhere during development anyway. 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.
Hmm, seems like the workflow you've described is a bottleneck leading to this. Wouldn't you have some kind of test/staging environment that is accessible for this purpose?
Re: API end to end testing with Docker
#25Earlier quoted context omitted.
I would simply say that testing APIs with pacts is a better approach than e2e testing.. Overall e2e testing is something you want to get rid off, cos development loop with it is too long and not modular. 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 surpris…
> Im surprised there are still ppl doing e2es. You're surprised that there are people actually testing that things work after integration, interacting with the system as a user would? I'm surprised there are still people who don't.
No, I'm surprised people still use e2e tests as they are not the best way to test what you described..
There are better ways, like the ones I've described. We are not longer in 90s..
ps. e2e tests are not the same as manual testing, so they do not even fully cover your case. They are expensive and take long time to run, while simple pact build step provides pretty much the same value and is pretty much instant while making it easier for all developer teams to track api changes..
Re: API end to end testing with Docker
#26Cool post, and pretty spot on. I've been doing this with Ruby apps, many of which interact with a browser, and I have some additional thoughts: - If you're running MacOS Catalina, make sure that you are using the Python version of Docker-Compose, not the compiled version that Homebrew installs. There's a bug with PyInstaller where it needs to fetch resources from the Internet after running any Compose command. This c…
Just wanted to mention (because I had encountered this problem only last weekend) `docker-compose run --service-ports... ` will expose ports. From docs: "Run command with the service's ports enabled and mapped to the host." https://docs.docker.com/compose/reference/run/ Also, for anybody wondering about "synchronization" solutions, I have found dockerize to be very useful. https://github.com/jwilder/dockerize
That's an awesome tip; thank you!
Re: API end to end testing with Docker
#27This 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…
> who cares if some function in your backend code does weird things when it takes a malformed string 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.
Agreed you definitely need both, but one is much more important to your company's continued existence.
To be fair, current best practice is to not write those tests at all, but to generate them and embrace the property based testing paradigm (ala quickcheck[0]). Put simply -- let the computer make random inputs and make sure your program maintains the proper invariants.
Re: API end to end testing with Docker
#28Earlier quoted context omitted.
> Im surprised there are still ppl doing e2es. You're surprised that there are people actually testing that things work after integration, interacting with the system as a user would? I'm surprised there are still people who don't.
No, I'm surprised people still use e2e tests as they are not the best way to test what you described.. There are better ways, like the ones I've described. We are not longer in 90s.. ps. e2e tests are not the same as manual testing, so they do not even fully cover your case. They are expensive and take long time to run, while simple pact build step provides pretty much the same value and is pretty much instant while…
You seem to be very focused on the API... but that's only half the product :-)