Goal
Show a simple setup of headless system testing inside a container with Ruby on Rails.
There are likely many ways to achieve this...
For further actions, you may consider blocking this person and/or reporting abuse
Hi @dougstull, thank you for this informative tutorial.
In some of the examples i have seen, testing is normally run outside the app artifact container, either in a separate container (as the first approach mentioned) or directly in a jenkins agent. It is beneficial because it results in a minimalist artifact image.
thoughts?
Hi Jack - thanks!
If I understand correctly you are referencing the ability to run the testing suite outside the app container...
With the rails system tests, the testing suite is integrated in the app git repo and is hitting the backend. If I stick to that approach to perform the system tests, then the only option I can see is to have the system tests run from inside the container for the app.
However, if we were using some testing suite that was perhaps testing a frontend framework instead, I could definitely see that as being the way to go as it perhaps wouldn't be so tightly coupled to the backend code/framework.
For this example I believe the benefits of utilizing the rails system testing suite outweigh the negatives. I assume that would hold true for me up and until a split of the frontend and backend technologies were to happen.
Hi Doug,
Yes, I am referring to the ability to run integration tests outside the app container. I believe that in capybara and headless chrome selenium driver, you can specify an external url to run the integration test. This enables CI agent to run the test against the docker container.
Docker images, at least the production ones, are supposed to have the bare minimum of what needs to get the job done. I think it should probably exclude all the development and test gems and I would also exclude the test directory.
If the purpose of the image is for test, then it is fine to run tests inside the container itself.