as I said, as a way to learn how the internals work as we start crafting testcases

I don't see us doing that any time soon, as the interfaces change a ton and it'd be very brittle for you to depend on.

right, I guessed y'all would say so 😄

Why do you think in process is better than just spinning up a container/process?

yeah, the recommendation is to use the

serve-testing

as an explicit interface we support, since it exposes the standard APIs

however there is a contract exposed right now, which is the server CLI

and I'd guess you'd want to honor that contract

so thought perhaps an API mimicking the server CLI would be ok?

(a go API, that is)

with semantic versioning, yes. There's a huge difference between maintaining the stability of the CLI interface and all of the code that goes into initializing a (test) server

I'm still trying to understand why you need it in-process

I'd like to hear more about that use case so that we know if we should be supporting it.

absolutely. If our team is making a commitment to run spicedb, we need to become comfortable with the codebase. Anything that helps our team understand the internal mechanics would accelerate our troubleshooting of problems and becoming proficient at upstreaming changes

we can certainly run the server separated and debug it as well, but thought from a developer productivity perspective that embedding it would be lower friction

not a deal breaker, but the kind of thing that I naturally gravitate towards in order to learn a new piece of technology

and in this case, since we run Go as well, it would be technically possible

I don't think a developer would even know the difference between using the code we use in our e2e tests and spinning up a server in-memory if the library that provided the fixture for both was sufficiently well designed.

FWIW, the code we use for creating test sets for our e2e is not very ergonomic and it would be nice to polish it up in a reusable way that others can import.

but that's a separate issue from needing to run a test server in-process

@User if there was a

github.com/authzed/spicedb/pkg/dockertest

package that provided two functions

NewServer(t *testing.T) (endpoint, readonlyEndpoint string)

and maybe a utility for getting a client for that server, would that be sufficient?

It would certainly spare me the need to build my own boilerplate to spin up the process, though it does not address the fact I'm not able to debug in my IDE of choice the code I'd be presumably be running in prod, unless I'm missing something

Why would you not be able to debug anything? I'm confused.

You mean set breakpoints in the SpiceDB internals?

yeah not having to attach manually the debugger just being it part of the running test

and understanding that the running test is a client application asserting client-specific behaviour

and yeah, setting breakpoints in spicedb internals

What kind of client-specific behavior are you wanting to assert?

authorization logic for a specific spicedb schema

so for example, ensuring that an application's HTTP handler performs a check request?