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!

Is DDD still relevant?

I heard someone mentioning Eric Evans and DDD (Domain Driven Design) a few times and so I decided to see what’s its all about. It took me a while to get through the book, partly because I’m a slow reader, partly because the book is long and partly because the read is dry. As I was working through the book, I often wondered to myself: “is this still relevant?”.

Lots of described techniques are common place in everyday software development, however some of them evolved, for example: Microservice. It represents a bounded-context and due to the nature of a microservice, it is separated and doesn’t share objects or internals. Translators, entities, value objects and aggregates are fairly standard on projects I’ve been in so far. Layered architecture, frameworks, team work, supplier-consumer team relations, managers, refactoring and ivory tower architects are fascinating subjects, but again been there and done that. I’m not a history buff but I do enjoy it and so I find myself smiling reading through some parts, lets not forget the book is almost 20 years old. I did find an answer to one lurking question I had for a while: “why less capable engineers tend to accumulate in a legacy but still important, core software systems?” and let me say, Eric nailed it.

So some techniques might be dated but in my mind still relevant, however all of it is just peripheral stuff. What about the core? What about domain? Well this is where things get muddy for me. As I read through examples and discussions, I understood the value of good design, born in ubiquitous language, with help of business specialists, capable fearless engineers with commitment to deep thinking and forever deepening understanding of a business model. In theory DDD is the best thing that can ever happen on a project, however in reality (and by some degree of the author’s own admissions and disclaimers), DDD is not always the best choice or even a possibility. In my mind too many things must align in order for DDD to happen and bare fruit. In any system with many moving parts, there are things that can and typically will go wrong, especially when we are talking about creative work and human operated system.

But is the book still relevant? I think so, I would not be putting it on the top of “must read before programming”, but it still be on the list. I’m sure that commitment to deep thinking and modelling will not be going away any time soon. On top of it, perhaps as an industry we are no long bounded by monolith, but bounded-context is here to stay in one form or another.

In a nutshell:
-: long, dry read
-/+: relevance of some ideas in present software development
+: methodology to design and implementation
+: covers lots of aspects of system development
+: plenty of discussions
=: the book is good, I think people aspiring to be or current architects will reap lots of benefits. Few things feel dated but lots is still very much applicable and valuable. There are lots of books and materials that hold (IMHO) more value for developers in early and middle stages of learning the craft. But at some point Domain Driven Design should be considered.

Title: Domain-Driven Design: Tackling Complexity in the Heart of Software
Author: Eric Evans
Cover:

Domain-Driven Design by Evans Eric

I took few notes during the read:

Domain-Driven-Design-notesDownload

Angular RxJS unsubscribe as a feature design

After few hours of thinking and more hours of implementation, I finally proved my idea is workable. I found it be a bit intriguing and so let me share it. Before jumping to the matter at hand, I would like to briefly mention that:

  • I don’t believe in end-2-end testing
  • I prefer unit testing
  • I like to test-drive my code

A few more details can be found here. On top of the above, I dislike using mocks, spies, stubs and other fakes to make testing “easier”. Now don’t get me wrong I do use mocks a bit, but mostly at a boundary (calls to backend, db and such). Let’s be reasonable, if code is a mess and/or legacy or there is a time constraint, options tend to dwindle and if you have to mock, you mock.

Now let’s see about my situation: I have simple app with navigation bar, located at the very top of the screen and top of the component hierarchy. The navigation bar contains search component. Below I have the main space with a router that happily swaps out different main components, depending where you click.

There is no simple way to pass data from the search component to presently displaying main component, unless we use observable, in particular Subject observable. So we have search observable and a main component is subscribed to it. The question is: “how do we test unsubscribe in the main component when we navigate away and the main component is destroyed?”.

After some thinking, I realized that NOT every main component is searchable, in those cases search component can be hidden. The approach has elegance to it, since it will help with testing and at the same time enhance user experience by eliminating confusing search feature that doesn’t seem to do anything when non-searchable main component is displayed.

On the other hand, when main component is searchable, then search component must be displayed so user can search it.

Ok, so how do we go about killing two rabbits with one bullet? We will enhance the search observable so it will count how many subscribers it has. Whenever any main component subscribes or unsubscribes to the search observable, the count will go up or down. Next a bit of elbow grease to wire up search component to hide/show when the count is equals to or less than 1 and we are done.

The whole logic can be tested by checking if the search component is displayed or hidden via jasmine spec, by navigating between main searchable components and main non-searchable components. No mocks, no spies, just elegant, user friendly feature and code design.

Decade with Accent

It seems the human mind likes round numbers – 10 year, a decade, all sound important. So here am I trying to grasp that it has been a decade since I bought my Hyundai Accent. Without any doubt it has been a journey, the car has seen a lot and I believe it is a good time for some thoughts.

Recently, I’ve re-read my reasoning to “why accent”, and at this point I wouldn’t be jumping the gun by saying: “I was right”. The vehicle got 241,702 kilometres on the odometer and never left me on the side of the road. Granted, I have always taken good care of the car and did proactive maintenance – complete log. It also doesn’t cost much to change out all fluids and filters earlier than needed, therefore the results are impressive – the car has plenty of life left in it. In addition, since it is a small car with small displacement, the amount of fluids required is also relatively small. Therefore buying high quality fluids is not a big deal. I remember after the purchase, my mechanic said: “this car will go for 300,000 kilometres easy” – back then I thought it was just wishful thinking, but now it seems more like a reality. The car is quite impressive in the reliability and repairability regard. I think one reason people don’t like cheap cars is because of perception: “cheap will break, but expensive cars will last”. Unfortunately, this is not the case.

Recently I was reading up on Suzuki Jimny just for fun. One thing that stood out like a soar thumb is technology in the latest release of Jimny – by 2018 standards, it is hopelessly outdated. Even the most cheapest vehicles on the market had direct injection for a while now but Jimny doesn’t. So perhaps cost of the direct injection is not a factor, so why would any automotive engineer pass-up an opportunity to make engine more powerful and efficient? I believe the reasoning is: old technology is simple and proven by time. Jimny at its core is dead simple, rugged and the most reliable thing you can through into the wilderness. Let me make it very clear – old technology is not pretty on paper – fuel economy sucks, power output is embarrassing and the rest you don’t even want to see. But on the flip side, it is dead simple, accessible, and reliable vehicle that will work for a very long time.

Coming back to my Accent, the concept of reliability is the same as with Jimny – old, but simple and simple means reliable and cheap to fix. Now I’m not saying let’s stay with port injection and 4 valves per cylinder forever and ever. What I’m saying is that as new technology comes out and is fitted into expensive vehicles first, where it is being tested in the real world. By the time it trickles down to the cheapest of the bunch, the technology has been fairly tested, and so cheap vehicles receive proven tech.

Now 3 years ago I said that next car will be either another Accent or Miata. Well I bought a Miata which opened up my mind to such a different experience. Driving anything after Miata feels very dull, I believe Miata ruined my driving experience of any other car. Miata entrenched my opinion: either get a car that makes you feel good or simply don’t bother – get the cheapest. Nowadays when I drive Accent, I simply appreciate it as a simple transportation. I guess I would compare the experience to getting on a personal bus and slowly rolling to a destination, nothing more or less. Back in the day I often thought about upgrading, modifying and otherwise changing the character of my Accent, to give it more bite, more edge, more driving “feeling”. Well I’m happy I didn’t go for that. Accent is a car with its own character and when you buying one, it is imperative you understand what it is, then you will not be disappointed.

P.S: “If I needed personal transportation I would buy Accent again”, but unfortunately it is no longer an option in Canada. Hyundai stopped selling the Accent.

Everything passes, this too will pass

King Solomon