Testing is all about being confident that your changes to the software can be deployed to production without problems. While unit or integration tests help you to test details — like the results of a calculation, or whether two parts of your system are working together — you don't know whether all parts of your system are working together as they should. Systems are getting ever more complex and we try to cope with that by splitting it up into parts so that we can handle them or distribute the complexity over multiple teams. Teams develop and deploy small, loosely coupled Microservices that reassemble a bigger system. How do you know that everything works together and that a user can use it? This is where End-to-end (e2e) testing comes into play. And Cypress can be a nice tool for that.
Recently I wanted to create the effect of a cable for an application I'm working on. The cable should have a textile look, similar to a rope, which is quite common right now (for example the charging cable of the current MacBook Pro). I'm using SVG for rendering, so applying a pattern to a stroke path should be easy, right?
Every software development team depends on architectural decisions. But more than often, the results of architecture discussions are never written down. This is a seed for future conflicts and software bugs, that can (and will) lead to unhappy developers and broken team productivity in the long run. But it isn't actually too hard to create decision records that are not overly complex or hard to create.
We recently released the stable 1.0.0 release of our prometheus_client package — a way to expose Prometheus metrics in your Dart application. It's inspired by similar packages like the official client_java for Java or the community package prom_client for Node.js. We have several Microservices written in Dart where we use the package to provide observability. I want to share the experience we had while developing the package.
I recently wrote about my indicators that I use while choosing dependencies in the NPM ecosystem. After writing the post I thought, can you automate these steps to provide a quick view on package health? One tool that does that is the Snyk Advisor. I tried the advisor and want to summarize my experience.
In my previous post, I wrote about choosing dependencies wisely. The NPM ecosystem is known for its small packages with a lot of dependencies. You can quickly lose track about your dependency usage. Do you have all dependencies configured correctly? Are all of your dependencies still in use? I want to present you depcheck, a small utility to keep track of your dependency usage.
Open-Source software brings great opportunities through a huge ecosystem of reusable packages. The NPM ecosystem grows by millions of packages each year. With so many packages, there is one for everything! There are central server packages like express, famous UI frameworks like react, widely used build tools like @babel/core, or helpful utilities like lodash. But there are also very specific packages solving niche problems, like a video container format writer based on JSX or an xkcd API client. But not every package is a good pick, often they turn out as a bad choice later on. To avoid regrets when choosing Open-Source dependencies, here are some points to consider.
If you are using react and test your components (you should!), then you are probably using the Testing Library. Testing helps to be confident that your components work as expected — especially in corner cases that are harder to test manually. The learning curve for a library can be steep, but doesn't have to!
Welcome to the Blog of Tentacle Labs! Recently we got inspired by a post on the StackOverflow blog. It highlights how developers benefit from expanding their skill of writing text, not just source code. One point got us hooked in particular: "if you can't teach it, then you don't really know it."