Skip to content

Add RegistrationService. This is a service for testing.#70

Merged
wolpert merged 2 commits into
codeheadsystems:mainfrom
bernata:registration
Jun 14, 2026
Merged

Add RegistrationService. This is a service for testing.#70
wolpert merged 2 commits into
codeheadsystems:mainfrom
bernata:registration

Conversation

@bernata

@bernata bernata commented Jun 14, 2026

Copy link
Copy Markdown
Contributor

It is used for testing to mimic the server starting and finishing a web authentication. The test code
wraps the registration service with http handlers. The client invokes the test http service to as part of its start, create credential, finish protocol.

It is used for testing to mimic the server starting
and finishing a web authentication. The test code
wraps the registration service with http handlers.
The client invokes the test http service to as part of
its start, create credential, finish protocol.
@bernata bernata changed the title Add RegistrationService. This is a service. Add RegistrationService. This is a service for testing. Jun 14, 2026
@wolpert

wolpert commented Jun 14, 2026

Copy link
Copy Markdown
Contributor

Where are you headed with the test service? One of the things I was doing was creating e2e tests via the example projects. I got a first pass at a CI job that does it, and if the CI doesn't fail me, is working now.

But with the typescript services you are doing, where are you headed? (Given the server is Java)

@bernata

bernata commented Jun 14, 2026

Copy link
Copy Markdown
Contributor Author

Where are you headed with the test service? One of the things I was doing was creating e2e tests via the example projects. I got a first pass at a CI job that does it, and if the CI doesn't fail me, is working now.

But with the typescript services you are doing, where are you headed? (Given the server is Java)

Yeah; probably should have put more detail in the first pr. Claude can write me a basic web authn server in typescript where i can test the client with happy paths and various failure paths. Its the failure paths that get the most benefit for having our own in-mem typescript service. While they [failure paths] are not that extensive in the client, they do exist: server start failing, server finish failing, browser credential fail, refresh fail, etc...

Its absolutely a good idea to have e2e tests; but i don't think they should be exhaustive; and they are not as easy to setup for debugging.

What do you think?

@wolpert

wolpert commented Jun 14, 2026

Copy link
Copy Markdown
Contributor

I think its reasonable as you can test various unhappy paths faster for sure.

The latest version has a gradle e2eTest task that will run from the client to the backend server via playwrite. When I set it up, I found the dropwizard and springboot worked fine, but micronaut had a bug. The only way I detected it was the by running the equiv tests against all 3 framework integrations.

I'm going to setup a discussion link for this stuff so we don't just talk though PRs on planning...

@wolpert
wolpert merged commit 84e8d7c into codeheadsystems:main Jun 14, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants