Mihai on the value of automating as many of your project’s Quality Gates as possible.

For instance, in my projects, I have rules ranging from cosmetic matters like naming or indentation to architectural rules such as “Classes are either abstract or final” or “All variables, of any kind, should be final”.

Martin Fowler’s TellDontAsk principle is very useful in object-oriented programming. However, it is not enough to follow only this idea: we also need to be very careful in order to not break the interface of the object, otherwise we won’t be able to keep telling it what to do later and we will end up asking for data again.

If we get rid of the concept of “model objects”, then there should be very little (almost zero) space for procedural code/algorithms in our codebase, since each object is a component that has its well-defined place in the bigger picture.

The following question arises: where does the “business logic” go? The answer is: business logic should be visible in how objects are wrapping/composing each other, rather than being visible in a 200 LoC method of some “service” class.

A visual explanation on why model objects are not a good practice in object-oriented software.

It is explained that a developer’s job should be the one of an engineer, instead of the one of a manual worker (I would say even the one of a puppeteer, but I don’t like the rhyme); objects should be alive and have behaviour of their own rather than being mere models surrounded by tools, artificial ways of making them act as if they were alive.

Mihai A:

If we agree that a RESTful API should offer more or less the same functionality as the UI, then we can use the same tests for UI automation and for API testing, provided that we make the right abstractions and link them together properly – this will guarantee that the API is navigable and respects the HATEOAS principle.

HATEOAS, for those wondering, stands for Hypermedia As The Engine Of Application State, which is a fancy way of saying the REST application exposes its state (where resources are and how you can interact with them) via hypermedia embedded in API responses. The advantage of this is:

A REST client needs no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia.

In practice, HATEOAS is often left off (which pretty much defeats the purpose of REST, but c’est la vie). The result is a “RESTful” API. Meaning it’s like REST but it ain’t really REST. I like well-designed RESTful APIs because they are easy to navigate logically, but true REST APIs don’t need to be navigated at all, which is way cooler.

But I digress, back to Mihai and this excellent post on testing:

The code that tests the UI should also test the API. It is achievable, provided that the architect pays as much attention on the tests as he does on the app’s code (which, sadly, is not always the case).

He goes on to show example code testing the GitHub API. Good stuff 👌