Showing posts with label Practical Programming. Show all posts
Showing posts with label Practical Programming. Show all posts

Friday, June 17, 2022

How to build stable and reliable System Test for Micro Services

Work in Progress, I'm currently overwork this article. Please come back later!

 

 

System tests are testing the orchestration of a bunch of micro services. Most of the test covers external features used by other micro services or by the front end.

If the current micro service is optimized for resilience (Yeah, Great) then system tests on feature endpoints can't discover errors related to (incoming) dependend micro services. The root cause of this lower power system test is the decoupling of micro services eg via the Fail Fast Pattern  or other Circuit Breakers (Thanks to Netflix). Or with other words resilience pattern could reduce the value of system tests.

System Tests improved by Diagnostic Endpoints

One way to avoid this negative side of resilience is to introduce what I called Diagnostic Endpoints. A diagnostic endpoint is only used by system test an not by features. The goal of diagnostic endpoints are to verify that functions that are covered eg by resilience pattern work.


In the real world, we save a huge amount of time after establishing of diagnostic endpoints. The software developers and the Project Owner love them.

Monday, February 7, 2022

Fail Fast vs Fail Early

If you look into Stackoverflow or so, you see tha Fail Fast and Fail Early used as synonyms. But that is not true. Let me just explain it.

Fail Early

Fail Early is working on method level.  The idea of Fail Early is to verify at method entry the parameters. The result is an early return or an early exception. The downside of fail early is that you have multiple exit points. That's why you have to keep your method short. But you have always to keep the method short or you handle different concerns in it.
At the end fail early is a technique to verify method parameters at the start of the method to avoid issues caused by data. The Lombock annotation @NonNull is a simple kind of fail early.

Fail Fast

Fail Fast is working on System Level. It's a technique to improve the resilience of micro services. It's a server side implementation of a circuit breaker. I developed this idea 2014 for a German company but I think many other software engineer also has the same idea. The fail fast pattern could be implemented in diefferent ways and for differen aspects of the software system. Now two examples of the fail fast pattern show the different aspect of it:

Fail Fast Example 1: Health Check

The micro service monitors his own health and if the service in unhealthy maybe because of an unhealthy or not responding subsystem the service can decide of fail fast some related (HTTP) request without going the whole service to the unhealthy state.

Fail Fast Example 2: Performance Check

The micro service monitors his own  request runtime. If the runtime exceeded a timeout the the service can cap the reuqest execution to free resources and response with an (HTTP) error code. This improves the performance resilience of the software system.

If you understand this pattern, you can imagine that are many more cases for Fail Fast.

Over all, the Fail Fast pattern avoid that slow or weak subsystems can shuts down all your services. It's a kind of an circuit breaker apttern.

Summary

  • The difference between Fail Fast and Fail early is the Abstraction Level. Fail Fast protects your micro service. Fail early makes your methods more stable. At the end you should use booth.



Thursday, December 24, 2020

How to name a method.

Class Names and Method names are more important like the most programmer expect. If your software is longer then 30 lines, you should invest some time to find a good name. If you don't know what I'm speaking about, please read this book Clean Code.

If you look more into the naming topic, you will see that the amount of method names or name patterns are very limited. But on service level you find a vary amount of strange names. To avoid mixups, following the SQL query pattern for method names, eg. 

List <Product> getProductsByCostumerIdSortedByDateAsc(final String customerId) 

is a rely good understandable method name, the concern is clear, and the meaning of the method parameter is clear and the side effect (sorted) is also clear.