Setting up a test-environment

[antiftw]

Hi,

I've been switching over to Docker and also familiarizing myself with TDD as well as a CI/CD setup, but I'm a bit unsure as to how to approach this, and have some questions about this process.

I've been trying to get a test-setup working on my development environment, but I seem to keep running into issues, so I was wondering if I might have the wrong approach, so I thought it might be a good idea to ask how others prefer to integrate testing into the process.

Since the Read-Me says this repository is CI ready, I assume you must have some kind of workflow thought out as to how this is implemented optimally/preferably?

Some concrete questions:

• For one: when utilizing CI/CD, is it common to only test on the test-server (using Jenkins for example), or do you also run tests on a local machine while developing?

• If so, what is the preferred way to set this up? Create completely separate containers, or re-use the development containers and only creating a separate test-database?

• How should one go about keeping this database in sync?

• What would the docker-compose files look like? Another 'override.yml' specifically for the test environment where we specify that it uses another database?

• If not, I am also really interested what the thought process behind this is. I can imagine that it's a bit weird to test locally and then just re-run the tests on a test-server, but on the other hand it seems a bit of a hassle (especially when using TDD) to push everything to a test-server before you can see the outcome of your tests. So I'm just curious as to what the general practice is regarding this, if any.

I would love to learn how to do this properly, so any pointers are greatly appreciated, not just from the repository's maintainers, but from the wider community as well.

As a side note: I do have some experience with writing tests, and have also been able to get testing frameworks functional using my IDE, it's mostly the integration with Docker and the CI/CD part that I'm having some issues with / uncertainties about.

Thanks in advance.

[tdumalin]

Hello @antiftw ,

I've recently discovered that this template is CI ready! and not so hard to use.
I'll let the CD part for another time.

So here's my answer to your questions:

1. I'd highly recommend to create and run your tests on your local machine while developing (using the TDD is up to you and doesn't change any thing on the CI configuration). The CI runs the same tests as your local machine does but it's purpose is to verify that when you push to the main branch, every thing works as it should be and you didn't break anything since the previous comit

2. With the template you can re-use your development container, check the "Build Docker images" in .github/workflows/ci.yaml under with.files instructions, the files compose.yml and compose.override.yaml are used to run the tests just as your development container. The database will be created automatically with a different name suffixed by _test

# config/packages/doctrine.yaml
# ....
when@test:
    doctrine:
        dbal:
            # "TEST_TOKEN" is typically set by ParaTest
            dbname_suffix: '_test%env(default::TEST_TOKEN)%'

When you install the symfony test pack all should be installed and work just fine to use the CI with phpUnit (you sould uncomment the if: false statement in .github/workflows/ci.yaml according to your usage doctrin / php unit

3. The database should not be sync with any of your local or production data. You should use fixture or some feature like resetting your database on each unit test (I'd recommend using Foudry

4. For basic set up, not need to create another compose.yaml file

5. Once again, test should be written on your local machine, the CI part just ensure on each push that the previous written tests works fine.

Hope this help

[antiftw]

Hi @tdumalin,

Thank you very much for the detailed answer!

1. Okay, that makes sense indeed, glad to hear that, since like I mentioned in 5, it seemed like a hassle to do things differently :)
2. This answer especially pointed me in the right direction, and the when@test config for Doctrine instantly made life a lot easier. Also, I have never heard of the Github-workflows so I will have to look into that, since that seems like something I should familiarize myself with.
3. Yes, I am aware of the fact that you shouldn't use the data from prod/dev and was actually talking about the schema, but luckily your answer to 2) gave me enough to go on since it now allows me to just run bin/console doctrine:schema:update --env=test to keep the database structure up to date. My apologies for not being more specific in my question. Regarding Foundry, I was actually already using that for the ResetDatabaseTrait 👍🏻
4. I have tried it out with the modification of the doctrine dbname_suffix, and have got it working with the original compose files. Nice!
5. Understood.

Again, thanks a lot, you've been very helpful, and I think I now know what I will have to look into to proceed.

Kind regards,