According to the 2021 test automation report, more than 40% of companies want to expand and invest their resources in test automation. While this doesn’t mean manual testing is going away, there is an increased interest in automation from an ROI perspective – both in terms of money and time. After all, we can agree that writing and running those unit test cases are boring.

Has it happened to you that with the release of a new version of your favorite application some feature disappeared? Or it works but unexpected things happen when you execute it? Or does it just crash? Today we will see what the possible tests that guarantee to avoid all of this are: regression tests.

When you think of TDD, you might lean towards Test-Driven-Development. Though in Tomasz Manugiewicz’s ACE 2022 talk, the ‘T’ in TDD could also mean Trust e.g Trust-Driven-Development. The talk, boils down to if there is trust, there is autonomy. If there is autonomy, creativity flourishes. Building trust is done incrementally, incremental success builds success. Software engineering is a team sport and an exercise in iteration.

Testing can evoke polarized reactions from developers. Some love it. Some prefer never to hear of such a suggestion. But acts of testing is necessary – especially shift left testing. Testing is often resisted by teams that are pressured by shorter release cycles tend to forgo testing altogether in order to meet deadlines. This results in lowered quality software, which can lead to security vulnerabilities and user experience due to defects.

When you develop software solutions, code quality and security are of top importance, and can often define your success or failure. Some teams may require a specialist constantly checking software for bugs and issues, especially when the project is large and unrevealed bugs can have costly consequences. For small development teams or early project development stages, developers may try to work without a quality assurance engineer and test everything themselves.

Testing today’s environments is more challenging than it was a few years ago. The transition to distributed environments has created complexity, overhead, and friction when writing and running new backend tests. These tests require a lot of preparation, infrastructure building, and maintenance since many services communicate asynchronously and they often miss exceptions that are thrown on the “deeper layer” of the system architecture and it’s hard to make it testable.

Node.js is well-known for its lightning-fast performance. However, as with any programming language, you might develop Node.js code that performs poorly for your users. Appropriate performance testing is required to combat this. Node.js can be used for a variety of tasks, including scripting to do tasks, running a web server, and serving static files, such as a website. Today, we'll go over the procedures to test a Node.js HTTP web API.

For developers who’ve created their own instrumentation with the Java Agent plugin, the next phase of the process is regression testing. By performing regression testing, you can ensure that your plugin functions the way it’s supposed to after you’ve made code changes or updates. You’ll have your own plugin, but to illustrate regression testing in this article, I’ll use the plugin in our example repo.