Do you find configuring mocks for your tests a bit painful? I was there for a very long time.
Now I found a solution that makes it a lot easier and I would like to share it with you.

I believe that maintainability is a key feature of the code you produce. It is good when your code works. But it is even better when it is maintainable in the long run. For many years I was not happy with my code. I was learning about encapsulation, SOLID principles and immutability. But none of this lessons taught me as much as reading Yegor Bugayenko blog and - what is more - his book. In this blog post, I want to give you a short example which shows his point of view so you can grasp the idea.

In one of the previous posts I have briefly described what is the Hystrix Circuit Breaker and why it’s worth to consider using it. Now I go more into details and explain what are the key parameters and how they affect its behavior.

Very often you might hear that it is good to have classes highly cohesive & loosely coupled. For many people, it may mean something a little bit different. So more important than just hearing to the slogan, is to have practical examples of what it actually means. In order to achieve loose coupling you should consider event bus at the beginning.

• Hystrix is a neat Circuit Breaker provided by Netflix.
• In order to protect external calls use the below code at simplest cases.

public class ForecastCommand extends HystrixCommand<Forecast> {
    private final String city;

    public CommandHelloWorld(String city) {
        super(HystrixCommandGroupKey.Factory.asKey("ForecastService"));
        this.city = city;
    }

    @Override
    protected String run() {
        return forecastService.forecastFor(city);
    }
};

void itCanBeUsedLike() {
    ForecastCommand command = new ForecastCommand("Krakow");
    String s = command.execute();
    Future<String> s = command.queue();
    Observable<String> s = command.observe();
}

• That way when a resource (forecastService) is unavailable for a reason, Hystrix will eventually stop calling it making your responses faster. And preventing downstream service from an exhaustion.

• I believe that switch-case construction is overused.
• Every time you branch execution depending on switch-case you’re doing something wrong.
• Instead of that you should move the logic into classes and rely on polymorphism.

• Do you have problems to keep up to yours no-commitments? Like do not eat sweets or do not buy yet another book?
• If you have, like I do, instead of punishing yourself with notifications & reminders saying “do not buy a book this month” give yourself a permission. And put it to a specific date.

• For most of the cases you should return Stream. It is more flexible, is designed for better performance, and can be easily turned into Collection.
• You should return Collection when there are strong consistency requirements and you have to produce snapshot of a moving target. Then you will want to put the elements into a collection that will not change.