Show HN: Laced – Interconnected unit testing framework
github.com
I'm building a dev tool that connects your unit tests to be tested together, simulating end-to-end tests.
I want to focus more on building instead of testing. So, I hope this dev tool will free up at least a third of our time daily.
It's currently only for TypeScript projects to ease building a proof of concept.
Currently, the tool can generate tests from a YAML file with spies and mocks. It can also help you debug by using spies and mocks.
Interconnecting unit tests are in the works.
Here's a usage example: https://github.com/nizarmah/laced-example
--- Rant
I've been working on an extensive integration at my job. Our team is eight folks working in parallel on different features.
In the best-case scenario, a third or half of every day is spent on test-related work.
For this project, I spent days regaining context, writing tests and instructions, testing manually, and debugging code and setups—all while reviewing and testing changes for my peers.
Not moving fast wasn't the problem; it was that constant paranoia and/or self-doubt. For example, if a change affected many other features with so many "branches" in logic, I would either feel like I wasted all my day testing or broke something unknowingly.
In the past, the team and I were able to spot concurrency issues more easily. I might be wrong, but I don't think I'm the only person overwhelmed with testing.
I tried alternatives. I start recording my testing process and linking recordings on pull requests. It helped others, but I still spent much time manually testing my changes and writing instructions for future reference.
I even dreaded writing unit tests because I would manually end-to-end test things anyway. Sprinkle battling with mocks and maintaining tests on top of all that...
If I haven't given it away yet, my experience was hair-pull-worthy.
--- Solution
----- Current
Right now, it reads your YAML file and generates unit tests. It doesn't work with all methods, only Function Declarations.
It uses TypeScript ASTs to transpile the YAML file into TypeScript unit tests. It uses Jest for testing (describe, test, expect, mock).
Briefly, it duplicates your code and wraps relevant areas to match the testing behavior in the YAML file.
For example, for mocks, it creates a proxy and replaces usages in your code with the proxy. That way, we can control whether we call the original method (spy), return, yield, or throw inside the proxy. And voila, a mock.
It becomes, then, easy to debug thanks to these spies and mocks. You can add one in less code than you'd need to log.
----- Future
I still stand firmly on the interconnection of unit tests. I haven't started working on it yet.
The current state is an attempt to make writing tests effortless. Once that's the case, it is where interconnection shines.
It's very easy to understand all the handful of results a method can return when creating unit tests. It becomes much harder when you start adding dependencies to the mix.
By connecting unit tests, we can start re-using unit tests from the dependencies inside the parent unit test. For example, if you're testing A which calls B internally, you can re-use B's unit tests.
You might already be doing that manually... At work, we have many test helpers which are just there to reuse data related to the same feature.
The end goal here is end-to-end test reliability at unit test speed. But it all depends on writing unit tests, which need to be effortless.
Anyway, it's still all speculation; we'll see.
--- Cheers
It's in a really early state, I know that.
So, give it a shot; be opinionated. Break it and open an issue with what's not supported yet. Leave a comment sharing battle-tested experience.
I'm here for it all. I want to build it for us all, not just myself.
Thank you for reading. Cheers!