New Unit Tests #93
magiccodingman
started this conversation in
Ideas
Replies: 2 comments
-
Okay I'm already glad I started doing this haha. There's significant |
Beta Was this translation helpful? Give feedback.
0 replies
-
@yueyinqiu i'm working on porting the e2e tests to the new magicdb V2 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
@yueyinqiu @Ard2025 Was just wanting to bounce some ideas. Since the version 2.0 launch the E2eTests have been non functional. Now as of right now the TestWasm project has ~100 unit tests thus far, but I am just trying to brain storm some better testing methods.
I am thinking about repairing the E2e tests because I miss the capabilities of utilizing the test explorer in visual studios. Plus they still test fundamental capabilities that're not yet fully tested. But there's other tests as well that I've been overlooking.
Dynamic Syntax Check
So the first idea I had was creating a system that would target the
.Where()
and.Cursor
and simply brute force every single allowed interface path. This way no more hardcoding every single path but auto checking every path.I'm not sure how to do it for the syntax part yet, but I want to also have different predicates in the queries as well that hit many different possibilities as well.
Indexed VS Cursor Queries
I need better tests that provide better confirmation of exactly what parts of the query was indexed and which were part of the cursor. As I need to make sure different paths that should or shouldn't be indexed are occurring correctly. I mostly manually validated these aspects but recent bugs showed me I had some mistakes. Additionally as things develop and change, I won't know if anything broke.
E2e Tests
The E2e test project was my fault for breaking. It fell apart after the new v2.0 was released. But it tested and validated both with magic indexedDB syntax and hardcoded dexie.js injected code to verify without a doubt that the results were correct or that they occurred. Since Magic IndexedDB wraps the engine in Blazor, silent failures are a danger and this project would catch such things.
Also the E2e tests didn't have caching issues which is super annoying for my WASM and sometimes the server project.
Final thoughts
I'm thinking of spending some time in the upcoming weeks making better unit tests and wanted to just throw this out there in case anyone had any ideas or thoughts.
Beta Was this translation helpful? Give feedback.
All reactions