how the hell do you guys test your full stack apps...

# ktor

[Manuel Lorenzo]

how the hell do you guys test your full stack apps, if there’s no tutorials/examples at all?

[Evan R.]

Docker-in-docker and cypress! You can bring up the full stack and verify user interactions from the frontend.

[Evan R.]

There also probably aren’t many tutorials because implementation of e2e tests can vary greatly depending on your app’s architecture

[Manuel Lorenzo]

docker-in-docker? cyrpress? what are those?

[Manuel Lorenzo]

ok in the front you can create react tests.. but what about the backend?

[Manuel Lorenzo]

and then what’s the proper architecture so I can learn how to test at least something? 😄

[Evan R.]

Ah ok lol I see where you’re at. There are lots of different types of testing. The big categories IMO are unit tests, integration tests, and end-to-end tests.

Unit tests will use a library like JUnit on the JVM or react tests on the frontend like you mentioned. These should be limited in scope to testing a single function or class to verify behavior. This is typically done for things like algorithmic verification and not stuff that calls out to external resources. If you need to call out to external resources it’s a good idea to mock these with a library like MockK so you can produce expected outputs.

Integration testing is like unit testing but involves testing the interactions of multiple different services, or even just expected responses from your HTTP server. Check Ktor’s testing documentation for how to get started on this: https://ktor.io/servers/testing.html

Now, end-to-end testing. This is like an integration test on steroids. It typically requires spinning up the full stack (front-end, back-end, database, etc.) and simulating user interactions with the web app. Cypress is an e2e test library which simulates user input into your web app so you can verify your app works the way it’s supposed to. Generally it’s better to do this in a CI/CD pipeline than doing it manually because it requires so much effort. Hence, docker-in-docker is a good choice (at least in my company’s case) because we run our Gitlab CI pipeline in docker containers. That way we can spin up the full stack in containers inside the test container then start the e2e tests to verify everything works.

[Evan R.]

Feel free to DM me for more info on this stuff, I know it’s a lot haha

[avolkmann]

i don't think ktor has any opinion on how to write your tests. Besides the test engine.

[Evan R.]

Yeah, I was just linking the Ktor test docs because of the test engine. It’s good for integration tests.

[Manuel Lorenzo]

big thanks!!