testing

I’m continuing my series on running the test suite for each Pull Request on Kubernetes. In the previous post, I laid the groundwork for our learning journey: I developed a basic JVM-based CRUD app, tested it locally using Testcontainers, and tested it in a GitHub workflow with a GitHub service container. This week, I will raise the ante to run the end-to-end test in the target Kubernetes environment. For this, I’ve identified gaps that I’ll implement in this blog post: Create

Imagine an organization with the following practices: Commits code on GitHubRuns its CI/CD pipelines with GitHub ActionsRuns its production workload on KubernetesUses Google Cloud A new engineer manager arrives and asks for the following: On every PR, run integration tests in a Kubernetes cluster similar to the production one. It sounds reasonable. Engineering manager: I want #integrationtests to run on the app deployed on #Cloud infra for each #GitHub PR ✅ Me, thinking it's a no

I’m still working on learning Rust. Beyond syntax, learning a language requires familiarizing oneself with its idioms and ecosystem. I’m at a point where I want to explore testing in Rust. The initial problem We have used Dependency Injection a lot - for ages on the JVM. Even if you’re not using a framework, Dependency Injection helps decouple components. Here’s a basic example: class Car(private val engine: Engine) { fun start() { engine.start() }

In my latest blog post, I advised reassessing one’s opinion now and then as the IT world changes fast. What was true a couple of years ago could be dead wrong nowadays, and you probably don’t want to base your decisions on outdated data. This week, I’d like to follow my advice. One of my first posts was advocating for TestNG vs. JUnit. In the post, I mentioned several features that JUnit lacked: No parameterizationNo groupingNo test method ordering Since JUnit 5 has been out

The subject of testing is vast. It may seem simple from outside, but it’s not. For example, one may define testing as checking that the software is fit for its purpose. But it encompasses a lot more: for example, mutation testing verifies that assertions do actually assert. In this post, I’d like to touch some testing flavors, what’s their purpose and how they compare to each other. The need for testing In an ideal world, we wouldn’t need testing. We would just write b

I was not a fan of assertions libraries at first. Whether assertions provided by the testing frameworks were enough is debatable. But those libraries provides the way to write custom assertions closer to the business language. While the intention is commendable, I always thought this path was a slippery slope. If one starts writing such custom assertions, then they need to be tested obviously. And then, when will it stop? However, there’s no denying assertion libraries make writing assert

This is the 5th post in the Starting Ethereum focus series. This post is part of a series dedicated on starting development with the Ethereum blockchain. Last week, we finally developed a contract providing some value in the form of a rough-around-the-edges voting application. Ethereum comes with no tools aimed at state-of-the-art software development out-of-the-box. Since this is a huge issue, there’s third-party tooling available in the form of the Truffle framework.

I have devoted a significant portion of my time thinking about designing and writing tests of all kinds. I believe my perspective can bring something to the table. In the rest of this post, I’ll follow the terminology proposed in the article.

15 years ago, automated tests didn’t exist in the Java ecosystem. One had to build the application and painfully test it manually by using it. I was later introduced to the practice of adding a main method to every class and putting some testing code there. That was only marginally better, as it still required to manually run the methods. Then came JUnit, the reference unit testing framework in Java which brought test execution automation. At that point, I had to convince teams I was part o

Most of our day-to-day job is learned through mentorship and experience and not based upon scientific research. Once a dogma has permeated a significant minority of practitioners, it becomes very hard to challenge it. Yet, in this post, I’ll attempt to not only challenge that sometimes tests must be ordered but prove that in different use-cases.

This week, my team decided to create a smoke test harness around our web app to avoid the most stupid regressions. I was not in favor of that, because of my prior experience with the fragility of end-to-end testing. But since we don’t have enough testers on our team, that was the only sane thing to do.

Working on a legacy project those last weeks gave me plenty of material to write about tests, Mockito and PowerMock. Last week, I wrote about abusing PowerMock. However, this doesn’t mean that you should never use PowerMock; only that if its usage is commonplace, it’s a code smell. In this article, I’d like to show an example how one can refactor legacy code to a more testable design with the temporary help of PowerMock. Let’s check how we can do that using the following c