starred/twofactor_gateway-nextcloud

Fork 0

mirror of https://github.com/nextcloud/twofactor_gateway.git synced 2026-04-25 00:55:52 +03:00

[GH-ISSUE #672] RFC: Integration Tests -- How To? #129

New issue

Open

opened 2026-02-26 05:33:26 +03:00 by kerem · 3 comments

kerem commented

2026-02-26 05:33:26 +03:00

Owner

Originally created by @rotdrop on GitHub (Sep 23, 2025).
Original GitHub issue: https://github.com/nextcloud/twofactor_gateway/issues/672

Just some brain-storming: this app adds means to obtain the second authentication factor via various service providers. It would be nice to have some "integration tests" -- ideally for all service providers. How could this be done? As most of the service providers require some sort of registration I suppose that this would require a test-account for each service provider (Signal, various SMS-Provides, Ouch WhatsApp etc.).

Perhaps one could ask for sponsoring? Concerning Signal one just needs any telephone number. For other services it might be different.

It would be cool to be able to perform real usage tests against the set of the currently -- perhaps -- supported providers.

Just writing this as an RFC (Request For Comments).

Originally created by @rotdrop on GitHub (Sep 23, 2025). Original GitHub issue: https://github.com/nextcloud/twofactor_gateway/issues/672 Just some brain-storming: this app adds means to obtain the second authentication factor via various service providers. It would be nice to have some "integration tests" -- ideally for all service providers. How could this be done? As most of the service providers require some sort of registration I suppose that this would require a test-account for each service provider (Signal, various SMS-Provides, Ouch WhatsApp etc.). Perhaps one could ask for sponsoring? Concerning Signal one just needs any telephone number. For other services it might be different. It would be cool to be able to perform real usage tests against the set of the currently -- perhaps -- supported providers. Just writing this as an RFC (Request For Comments).

kerem commented

2026-02-26 05:33:27 +03:00

Author

Owner

@vitormattos commented on GitHub (Sep 24, 2025):

One possible approach is to use unit tests, generating mocks of API responses. The LibreSign app has some tests similar to this, which I've done using the project https://github.com/donatj/mock-webserver. I'll think about this further and perhaps create a pull request as a proof of concept.

@vitormattos commented on GitHub (Sep 24, 2025): One possible approach is to use unit tests, generating mocks of API responses. The LibreSign app has some tests similar to this, which I've done using the project https://github.com/donatj/mock-webserver. I'll think about this further and perhaps create a pull request as a proof of concept.

kerem commented

2026-02-26 05:33:27 +03:00

Author

Owner

@rotdrop commented on GitHub (Sep 24, 2025):

One possible approach is to use unit tests, generating mocks of API responses. The LibreSign app has some tests similar to this, which I've done using the project https://github.com/donatj/mock-webserver. I'll think about this further and perhaps create a pull request as a proof of concept.

Yes, but this adds another bunch of things that need to be kept in sync with the numerous providers. It also does not cover changes in the API which may or may not be announced by the providers. I think that "real integration tests" which access the currently implemented APIs of the numerous providers are easier to maintain and more likely to catch errors as this would be closer to the real-life usage.

@rotdrop commented on GitHub (Sep 24, 2025): > One possible approach is to use unit tests, generating mocks of API responses. The LibreSign app has some tests similar to this, which I've done using the project https://github.com/donatj/mock-webserver. I'll think about this further and perhaps create a pull request as a proof of concept. Yes, but this adds another bunch of things that need to be kept in sync with the numerous providers. It also does not cover changes in the API which may or may not be announced by the providers. I think that "real integration tests" which access the currently implemented APIs of the numerous providers are easier to maintain and more likely to catch errors as this would be closer to the real-life usage.

kerem commented

2026-02-26 05:33:27 +03:00

Author

Owner

@vitormattos commented on GitHub (Sep 24, 2025):

Real integration tests have some complexities because they depend on managing access credentials. This can create a security issue, as it will allow messages to be sent by multiple providers by anyone with permission to create a pull request that automatically executes CI. Another point is that they are highly susceptible to failures because the external service may not be working for some reason.

If we assume that the code is compatible with the provider's version at the time of the code creation, mocking may not be a problem but a solution to signalize that the implementation respect the API contract. New versions of the providers will certainly break (or are already broken, as there's no way to validate all existing ones) and at this case, opening an issue could be easier and safe.

@vitormattos commented on GitHub (Sep 24, 2025): Real integration tests have some complexities because they depend on managing access credentials. This can create a security issue, as it will allow messages to be sent by multiple providers by anyone with permission to create a pull request that automatically executes CI. Another point is that they are highly susceptible to failures because the external service may not be working for some reason. If we assume that the code is compatible with the provider's version at the time of the code creation, mocking may not be a problem but a solution to signalize that the implementation respect the API contract. New versions of the providers will certainly break (or are already broken, as there's no way to validate all existing ones) and at this case, opening an issue could be easier and safe.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/twofactor_gateway-nextcloud#129

No description provided.

Rows
Columns