Abstract classes typically offer one or more concrete methods. These must be tested as well. There are several ways how to do it, but which one to choose?

Object-oriented approach is a mighty concept making software more maintainable, which means cheaper and easier to understand. Problems come at boundaries, where objects have to be passed on into a different layer or another system. There, the objects become just data and should be treated like that.

Noone wants to write one thing twice. Reducing duplicates makes code shorter and clearer. How much this applies for test code?

I really like Test-Driven Development (TDD) and apply it almost always. The problem with TDD is that it focuses too much on working software.

One reason I really like the serverless architecture approach is being pretty selfish: one has to care only about what matters - the code.

How to proceed when shared data are needed?

Binary data shouldn't be a part of the codebase. This is pretty well-known practice. But how to proceed when we do need binaries in our codebase, for instance as test data?

Write your tests once and run them twice - as both unit and integration tests - sounds like a good deal, let's take a look at this practice.

Black-box testing is testing of a component via its API without any knowledge of its implementation details. As the opposite there is the white-box testing. And it about testing implementation, right? Well, no...

Continuous delivery (CD) brings a lot of ideas essential for a modern software product deployment. In this article we discuss how to follow CD principles by building CD pipelines with an example in AWS.