Case Study: Debugging locally using Jest tests & Sprkl

As a founder, a happy user is one of the most exciting things! It feels great to be reassured that Sprkl helps devs effortlessly get the data they need to improve their code. It makes me even happier if the user shares his positive experience with the world out of his own initiative. So obviously, I was so thrilled to discover this article, written by Albion Bame.

🐧 Albion Bame is a software engineer living in Germany. He has a great blog space you should check out:

In this post, I wanted to share a few critical takeaways from Albion’s article: the pain he and his team struggled with and how they solved it using Sprkl.

The pain: Albion and his team struggled with using their Jest tests results to debug their code locally efficiently

“Development is a complicated process that includes a lot of steps and things to consider. It becomes even more complex when we validate our implementation with tests and coverage.” 🐧

“In a production environment, we have a lot of tools and technologies to do that, like for example, the Elasticsearch-Kibana-Fluentd combination.” 🐧

Don’t get me wrong, we can use the same tools locally, but with downsides, since all three of these tools rely on Java and use a lot of resources but also don’t provide us with a lot of information that we need during development. These tools are really good for monitoring but not the best tools for debugging.” 🐧

How Sprkl helped:

“If we run our tests with Sprkl, we’ll see the results and the dashboard with a really nice timeline like the image below. In my case, I executed only one test with the following command sprkl — yarn test PATH_OF_TEST.” 🐧

“We see in the interactions section that out of two tests, one of them is not changed and one of them is changed since we did some updates in one of the methods of the component. Also, from the coverage section, we see that from the method that we changed 50% of the code of that method is not covered by tests. If we click the Sprkl icon from the test execution timeline we’ll jump directly to the code that is not covered with tests.” 🐧

Watch Sprkl in action: Debugging locally using Jest tests & Sprkl

How is Sprkl different: The Personal keyword

“The most important part here is the Personal keyword. I say that because this tool will give you reports only for the part of the code you changed and only that.” 🐧

My turn: Get OpenTelemetry and Jest to speak with each other 

Not all of you know, but OTel and Jest are not built to work with each other. Therefore, making your Jest tests observable takes a lot of effort. We took this effort as we believe it’s extremely useful. Sprkl gets OTel and Jest to speak with each other and provides observability to your Jest tests.

With Sprkl POP, you can quickly determine if your Jest tests failed due to your recent code change or simply because of their flakiness. 

Sprkl natively supports Jest-based testing (unit and integration tests), with insights and traces for every execution. You can easily analyze failed tests, including details for mockups and assertions. Sprkl also shows you which specific tests passed through your recent code change and which didn’t.

We have a dedicated blog explaining how to add OpenTelemetry Observability into your Jest testing frameworks and squeeze Jest for better performance.

FAQ

What is Sprkl? 

Sprkl is a Personal Observability platform that provides developers with telemetry data and actionable insights about their own code changes. We leverage OpenTelemetry to instrument every code change and analyze it upon execution.

What languages does Sprkl support?

TS, JS over Node.JS (Node V.16 or higher).

Do I need to install Jaeger?

No. It comes out of the box: No need to deal with the hassle of installing it into your IDE.

Is Sprkl free?

Yes, and it will always be free for an individual developer. The only thing we appreciate in return is your feedback and spreading the word amongst your fellow devs and communities that you engage in.

Curious? Join our beta