End-to-end (E2E) testing is a powerful tool for automated quality assurance. Ideally you want to be able to catch potential errors and bugs already on the unit testing level, but doing so can sometimes be both time-consuming and difficult. Unit testing also relies heavily on mocking out dependencies by nature, so we cannot necessarily guarantee the same behaviour as in our live application. E2E tests are on the other hand often very straightforward to set up and write, and enables us to construct very realistic testing scenarios.
Let’s take a simple example from the world of JavaScript, where we can’t be certain of the type of a variable up front. Let’s say we have a function (myFunction) which we can either pass a string or an array of strings. If we pass it a string, we want to do something with that string. If we pass it an array, we want to do the same thing for each element in the array.
A common challenge in software development is how to decide and then fulfill non-functional requirements, such as the maximum response times of your API. Two metrics to consider is the average response time of a certain endpoint, as well as the percentage of outlier requests that will fall outside of the accepted time bounds. Such outliers will always be there, especially when designing a microservice architecture using lambdas with their dreaded cold starts which is common these days.
The Whole Value Pattern is a pattern first described by Ward Cunningham in 1994. It simply implies that a value should always be stored together with its corresponding unit, which together forms a “whole value”. A lone numerical value is usually not meaningful on its own, without a corresponding unit, and is therefore a violation of this pattern.
The main benefit of following the Whole Value Pattern is that implicit developer knowledge can be made explicit in the codebase instead.
Rewriting a large piece of software from scratch is usually not a good idea, regardless of how messy or problematic the original/legacy code is. The reason is that you never know how long the rewrite is gonna take, what unexpected problems you might run into or even if your new solution is gonna be any better than the old. You might end up spending several months on refactoring without any possibility of releasing anything into production until the rewrite is complete.