Automated Testing — A Primer for Software Engineers

The Lone Architect — Mon, 28 Nov 2022 06:19:14 +0000

Are you testing the apps you’re creating ? No matter how you think about it, there’s always someone doing so (unless no one uses your app, which is sad). And sooner or later, someone will notice a dysfunction. Some will ring the bell but most will just leave and never come back.

What’s the conclusion ? The earlier you catch defects, the easier it is to solve and the cheaper it is for the company to run the business.

And there’s different stages at which these defects can be caught, from worst to best :

Never : some just don’t happen, at least until now. And you can’t even measure the gravity of the bug before it happens.
Once in the hands of end-users : and you’d be lucky if they have you noticed about it
In the QA phase : if you have a dedicated team (which isn’t always the case), they may test your app against their own manual test suite, but that’s typically weeks after the code that provoked it was written.
In the Build Pipeline : you may catch it by the end of the day or a few days after the code was committed and tested against various high-capacity tests
Before the commit : typically minutes or hours after the code was written, so it’s still hot and is still easy to solve.
During the code : that’s literally minute one. That’s the cheapest moment to solve the bug.

In a few lines, we covered quite a few topics, all related :

Manual Testing
Automated Testing
Test-Driven Development
Continuous Delivery
Unit Tests
Integration Tests
Acceptance Tests
End-to-End Tests
Smoke Tests

If all of that sounds cloudy to you, then you’re at the right place. We’ll take a good peek and sum up at all things related to tests.

Read the rest of the article on blog.thelonearchitect.com.

A gentle introduction to Domain Driven Design

The Lone Architect — Wed, 23 Nov 2022 02:07:54 +0000

Starting into DDD is hard, even though it’s heavily praised by their practitioners. The topic is widely covered in the now infamous “Domain Driven Design” by Eric Evans (Blue Book) and “Implementing Domain Driven Design” by Vaughn Vernon (Red Book).

Both of them are terribly verbose and thick, which is no surprise coming from Java engineers. The material is dense and there’s a lot of noise around the main ideas, which makes the barrier to entry even bigger for newcomers. Many times, I’ve felt like i’m too stupid to understand what StackOverflow made obvious after few researches.

Although the verbatim is complex, the ideas behind are rather simple and easy to grasp. When it “ticks”, it just becomes common sense.

It’s all about the business

Here’s the main gist : domain model should be kept separate from the dangers of the outside world, and interfaces are the bridges connecting the dots. That’s also the basis for Hexagonal Architecture, Clean Architecture, Onion Architecture, and all the other trademarked terms that more or less boil down to the same principles.

They are all domain centric.

But Domain Driven Design takes it a step further and gives the tool to structure and develop the domain itself, while the others architectures are just a mean to encapsulate the domain. In other words, you can do Hexagonal without DDD, but you can’t really do DDD without layers around.

I believe both the blue & red books are opaque about it. You’ll be tempted to believe you either go DDD or you don’t, there’s no in-between. Which is the reason I’ve been discouraged from trying DDD altogether.

But Vlad Khononov took another approach. In his book “Learning Domain-Driven Design” (affiliated link), he starts with the very basic and foundational principles of DDD, which are Subdomains, Bounded Contexts and Aggregates. He then establish a scale of usability. Depending on the task at hand, you might not need to do DDD. For once, a book that introduces DDD and isn’t all-in.

One shouldn’t use a complex tool for a trivial problem.

I loved this approach and found it more genuine and useful than the other two books. Let’s see how it unfolds.

Disclaimer

I am by no mean a DDD guru or expert, but rather a learner who condensed his knowledge inside this article. I hope to provide the kind of introduction I wish I had when I started this adventure. DDD is a complicated topic, so always double check your assumptions.

👉 Read the rest of the Article on Medium

DEV Community: The Lone Architect

Automated Testing — A Primer for Software Engineers

A gentle introduction to Domain Driven Design

It’s all about the business

Disclaimer