Skip to content

integration tests#52

Open
tomas-kulhanek wants to merge 3 commits intofakturoid:mainfrom
tomas-kulhanek:integration_tests
Open

integration tests#52
tomas-kulhanek wants to merge 3 commits intofakturoid:mainfrom
tomas-kulhanek:integration_tests

Conversation

@tomas-kulhanek
Copy link
Copy Markdown
Collaborator

@tomas-kulhanek tomas-kulhanek commented Jan 14, 2026

Add integration tests

@tomas-kulhanek tomas-kulhanek force-pushed the integration_tests branch 3 times, most recently from e901769 to 00c627b Compare January 14, 2026 22:58
@tomas-kulhanek tomas-kulhanek marked this pull request as ready for review January 14, 2026 23:03
@tomas-kulhanek
Copy link
Copy Markdown
Collaborator Author

tomas-kulhanek commented Jan 14, 2026

@ollie
please check only last commit Because this is based on #54

Refactor integration tests and improve type handling in various classes

Add integration test workflow to GitHub Actions
@tomas-kulhanek tomas-kulhanek self-assigned this Jan 14, 2026
@ollie
Copy link
Copy Markdown
Contributor

ollie commented Jan 15, 2026

Is this #54 a prerequisite for this PR to run properly? I'm getting same unautohrized errors in both unit tests and integration tests in this branch.

@tomas-kulhanek
Copy link
Copy Markdown
Collaborator Author

@ollie
This is how I did it:

  • composer install (if you've done this before, run composer update, because there are new dependencies)
  • cp .env.example .env
  • fill in the correct data in .env
  • composer test:phpunit

If you look at Github action, the unit tests are fine and the integration tests fail because there is no data in secrets, see yesterday's email.

@ollie
Copy link
Copy Markdown
Contributor

ollie commented Jan 15, 2026

Ah, we may have misunderstood what integration tests are. In our world they don't connect to external service, so you still have to mock things, but you just test more interconnected steps. I don't think we'd want to do this against production DB, but we have staging server which could be used for that, just need some input from Eda if he'd like that or not.

@tomas-kulhanek
Copy link
Copy Markdown
Collaborator Author

Sure, that would be great. We could call it acceptance testing. But in libraries, technically, I think they are integration tests.
Running against production will definitely not be the best option.

We could make it so that they don't run automatically, but leave them for manual execution. At that point, they wouldn't run in GHA, but the developer would run them themselves on their machine.

@ollie
Copy link
Copy Markdown
Contributor

ollie commented Jan 15, 2026

Makes sense. It would require to override the main URL endpoint. I'd still wait for Eda before hacking things further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants