Month: September 2021

Mastery

Ah mastery, who doesn’t want to be a master? A rhetorical question, yet an important one.

I’ll come back to the question later, but for now, how is the book? I like it, strange to say from the get-go but yeah… I enjoyed the story, examples & discussions. The book takes mystery of being a genius and breaks it down into concise, foundational sequences of events that each master had to go through in order to climb to the top of their respective field. Each event and a sequence is analyzed by the author and discussed. If you ever wanted a guide on “Mastery”, this might be it.

As I was going through the book, I couldn’t help but ask myself: “well, alright, but who is this book written for?”. Is it a recipe book? I’m not sure, some of the recipes are kinda long – start when you are 5 or 10 year old. Sure, mastery takes long time, you can’t be on the top of a field in just couple of years or by following few “easy” steps. I get it, but it doesn’t answer my question. If you got this book and comprehended it by the age of 17, perhaps you can make it, but for anyone over 30 there aren’t that many recipes in the book. To be fair, the book is fascinating and at any age you should take some ideas out of it, but let’s be real, in order to take full advantage, you should be at the very young age – perhaps you can prepare your children for the journey?

But do you want to be a master? Is it even a conscious choice? I don’t know, but overarching theme seems to be outliers. Those masters have a very different view of the world, some don’t even fit into society. It feels to me that the journey starts with a perceived defect in a person. Something deep inside drives those people forward, some get unlucky and go to live on mountains (figuratively speaking), others get lucky (timing, resources) and lunge forward through many years of hard work but in the end some become dazzling stars of our society, providing example and direction for others to follow.

In a nutshell:
+: Easy & fun read
+: History, analysis, discussions
+: Examples from different eras
+: Useful bits and pieces even if you are not planning on a mastery
-: Is mastery a choice?
=: I don’t know if mastery is a choice, but I can still learn quite a few things from the book. Perhaps if you are young, you should read the book early on. If you have children, perhaps you want to read it as well and set your child on a journey. But perhaps you want to explore minds of the masters for the fun of it, then please enjoy.

Title: Mastery
Author: Robert Greene
Cover:

Springboot test custom client, controllers and/or filters – a quick way

Recently I posted a question to the stackoverflow (please check it out first). Unfortunately I didn’t have time to explain – ‘why?’

Also I don’t think stackoverflow allows lengthy debate in the comment section. So I would like to make a quick explanation and hopefully have a debate in the comments.

Ok, so, why would you want to test service client and associated controller (springboot service) in the same unit test? I believe the case is fairly narrow and following conditions should apply:

  • Microservice must come with an associated client, which is capable of executing all available endpoints (in my case: internal microservice policy)
  • Client is complex!
    • Serialization and deserialization of objects
    • Uniform handling of errors (internal errors)
    • Custom security (internal use)
    • Custom compression
    • Logging
  • Controller is thin (just a delegation to a business layer)
  • Limited/Inflexible build pipeline OR time constraint on unit test execution (let’s say if test takes more than 4-5 seconds)

Now here is a list of ‘usual suspects’ to why NOT test client and controller together:

  • Service and client are separate ‘units’ therefore SRP and/or separation of concerns
  • Client is simple and can be tested separately
  • Controller can be tested separately
  • Fast/flexible build pipeline and/OR no time constraint

I would like to defend my approach:

  • Unit test is very flexible term – I believe developer/business can define what unit actually means. In my case, internal policy states that if I develop new endpoint and/or service I must provide a client, that will comply with company’s internal needs. So a unit of work in this case is client and associated endpoint/s, one can’t exist without the other – therefore one unit.
  • Client is not simple at all. Luckily most of the internal logic is abstracted away, so I can reuse abstraction and focus on immediate things like: path params, path variables, method and payload – which should be tested.
  • Controller in my case is thin one – meaning there isn’t much code there, typically one line – delegation to business layer. So I can test controller separately, but there isn’t much value. The value of the thin controller is in correct delegation and entry point (paths & params specified correctly).
  • Build pipeline is important tool, however if it is slow, constrained and inflexible, it becomes major source of headache (and sometime creativity). If your test brings up service and in process takes up a port and 10-18 seconds to start up, well the test will be ignored/removed in the name of performance – no value in that.

I hope this reasoning (along with stackoverflow solution) will be useful and helpful for those in need. Please share your thoughts.

Thank you!