Add unit tests

[mvares]

It's necessary to maintain our integration with testing at all levels.

• We should start with the library module and then move on to the following modules.

---

[kearfy]

Hiya! Thanks for the suggestions.

I've been meaning to improve testing for the JS library for months already! But I can't find the time for it unfortunately. The difficulty in this particular project is that we support both deno and node/bun (officially). Because of this we need to either:

• Split the tests for deno and node/bun, which leaves us forced to maintain two sets of tests
• Write a custom test suite which is much more work and what we currently do

I'm leaning to change it to the first option and hope to get to this soon, so we can properly test every function

[PGilbertSchmitt]

@kearfy I enjoy writing tests for some bizarre reason. I think unit tests should be trivial to write using the same structure as the E2E tests, without needing a running docker container. No duplication, 100% coverage, the whole shebang. I can try to tackle that this weekend.

EDIT: I must admit my embarrassment. Without mocks or the ability to spawn a mock server, this is much more challenging than I anticipated. With mocks this is trivial, but adding a mock library is not so easy when testing in deno AND node/bun at the same time.

[kearfy]

Haha! Well, to be honest, I'm not sure what the benefit is of using mocks here is surrealdb is so easy to embed in any environment really :)

If you see a way to improve the tests I am definitely open to it!

[PGilbertSchmitt]

Unit tests would be less about embedding SurrealDB and more about checking that the library itself does what it's supposed to. Your blackbox E2E tests already do the former. I believe ideal unit tests would be calling each method of the client classes and verifying that the mocked WS/HTTP server is receiving the correct message, then verify additional behavior by mocking responses. This is white-box testing, where we don't rely on the behavior of SurrealDB to test SurrealDB.js.

A mock server in this instance would mean hosting a fake HTTP server and a fake WS server and being in control of their behaviors during the tests. The HTTP server is easy to implement without libraries thanks to the builtin http module, but the fake WS server is more challenging, we would need to use a library for that. The ws module is already a dependency of the full app, but that's built using a script into the /npm directory, so inaccessible to the tests. If this is the direction for unit tests, the deno and node/bun suites might need separate package.json files.