Skip to content

test: Introduce fakes for app config#61220

Draft
artonge wants to merge 2 commits into
masterfrom
artonge/test/introduce_fakes_appconfig
Draft

test: Introduce fakes for app config#61220
artonge wants to merge 2 commits into
masterfrom
artonge/test/introduce_fakes_appconfig

Conversation

@artonge

@artonge artonge commented Jun 11, 2026

Copy link
Copy Markdown
Collaborator

The goal is to reduce the dependence of most tests on actual implementation and in the end the database.
This also make it much easier to prepare the environment for tests.

I used the fake in some tests to try out, and it is indeed easy and clean.

@artonge artonge requested review from Altahrim, come-nc, leftybournes and salmart-dev and removed request for a team June 11, 2026 19:59
@artonge artonge self-assigned this Jun 11, 2026
@artonge artonge added the 3. to review Waiting for reviews label Jun 11, 2026
And use it in some tests

Signed-off-by: Louis Chmn <louis@chmn.me>
@artonge artonge force-pushed the artonge/test/introduce_fakes_appconfig branch from 586292c to 3ae19a2 Compare June 11, 2026 20:04
@artonge artonge added the tests Related to tests label Jun 11, 2026
And use it in some tests

Signed-off-by: Louis Chmn <louis@chmn.me>
@artonge artonge marked this pull request as draft June 11, 2026 21:45
@artonge artonge added 2. developing Work in progress and removed 3. to review Waiting for reviews labels Jun 11, 2026
@ChristophWurst

Copy link
Copy Markdown
Member

This is more of a convenience helper, right? Because mocks already allow us to have that

@artonge

artonge commented Jun 12, 2026

Copy link
Copy Markdown
Collaborator Author

This is more of a convenience helper, right? Because mocks already allow us to have that

My problem with mocks is that it is super lengthy to configure all the expected interactions that the tested method will have. Also, it binds the test to the implementation, so every time the implementation changes, the test needs to change too.

Currently, this is rather an experiment, I'll try to pick it up again when I have time.

@ChristophWurst

Copy link
Copy Markdown
Member

I agree for tests that use the at/consecutive pattern. They are fragile and you are indeed testing the internals.

(App) config should be arranged like $config->method('getValueBool')->with('maintenance')->willReturn(true) so call order doesn't matter. In fact it doesn't even matter if the config is fetched or not. You just set up the environment.

Just my 2c

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

Labels

2. developing Work in progress tests Related to tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants