DEV Community: Marko Bjelac

Socrates Deutschland 2025

Marko Bjelac — Mon, 21 Jul 2025 22:27:00 +0000

My colleague & me were on the Socrates un-conference in Soltau, Germany.

This was our 2nd Socrates, as we were both at the UK version last year.

Comparison with the UK conference is not very interesting: There were more people than in the UK (this is usually the biggest Socrates by far) and the hotel was new, built specifically for conferences & gatherings. Other than that the venue type was similar and the people were as smart, as kind & as inviting as in the UK.

Comparison with other conferences and life experiences in general is close to impossible. The German Socrates is as radical as the UK Socrates in more than one aspect.

🔪 Aspects

Socrates is a complex endeavour and describing it is difficult. Hence I will do the engineering thing and analyse it. This means chopping it up into pieces (calling them “aspects” to sound like I know what I’m doing) so I can better understand it.

🛠️ Professional

I met a bunch of very very very smart people! These people know a lot & love to talk and to teach about various software crafting and other skills. Their accessibility is the most radical thing. You just ask someone to show you something or talk to you about something and they’ll eagerly accommodate you.

For example, I was on a session describing a mad form of TDD (MAD-TDD) and that evening I realise that the way we do BDD at my current project has some resemblances. At lunch the next day I ask the speaker would he pair with me on an idea related to mad TDD. At dinner that day we pair on a small experiment and I am now ready to explore MAD-BDD!

Everyone’s schedule is full and everyone wants to get to the next session or play a board game, but they’ll all make room in their schedule for you and go out of their way to teach (and with that, to learn) about anything you ask.

There is more patience accumulated at Socrates than at 7 kindergarten-teacher conferences. 🍼

👫 Social

Some issues can’t be explained by Clean Code or any other technical book. A lot of sessions and conversations were about agility. Put differently, they were about the social systems which are created to build software. These systems are complex and seldom optimal. Agility as a term is warily used nowadays (walking on eggshells 🐣) however there is an understanding that the original idea was OK. Some attendees are extremely experienced in navigating those systems and gave the rest of us very valuable advice.

Also, managers are apparently not evil. 🤷

🌍 Worldly

The world is being eaten by software. This is old news. We can’t do anything about it but we can try to ensure the software systems we create do not enforce injustice. Or can we?

Is it inevitable that companies grow to treat their employees like resources?

Is there any viable alternative to the already established techno-feudalism of the ultra-rich?

Now, that’s heavy subject matter. So heavy in fact that I skipped one of those sessions to listen to escape room 🔒 building skills - metaphorically and literally escaping, heh heh.

However, I did attend a couple of those sessions, the last one having dark but towards the end also some lighter notes which left a tiny spark of optimism in me. 🌈

🍭 Playful

Socrates would not be Socrates without some serious silliness. Most of us there are engineers after all.

Among these unconventional activities (ha! as if others were conventional) there were

billiards 🎱
board games 🎲
volleyball 🏐
table-top roleplaying games 🧙 (only one but that was awesome)
programming robots 🤖
intentionally destroying a codebase by refactoring 🧨
and petting a very nice dog called Luca 🐕

Sober or not 🍺, long conversations about wildly amusing & diverse topics were to be found in every corridor.

I went to sleep late every night, reluctant to leave the conversations. But I wanted to get some sleep for the next day. However, lying in bed I couldn’t fall asleep because my mind was excitedly racing through the events of the day. After I finally fell asleep I would awake the next morning 1.5 hours before the alarm clock, my body still tired but my mind yelling: “Come on, lets go on the ride again, and again, and again!” 🎢

Now at home, after I finally got a night or two of decent sleep I fall into the daily routine again. While going about regular tasks I smile when a memory from the past couple of days pops up and waves to me in passing.

🥳 In closing

Socrates was (again) a warm and inspiring experience. I felt at home with people whom I (mostly) met for the first time in my life. This is what every conference should look like. This is how people should communicate, learn and teach, always.

While waiting for the next year’s Socrates I will not be idle. I will try to spread the experience by organising monthly meetups in Zagreb and any other close-by city that will take me.

What meetups? These meetups: https://www.meetup.com/zagreb-software-crafters/

To wrap this up, I would like to thank:

Conference organisers, the most selfless beings on the planet: Accept a big 💋 from me!
All the other attendees: Stay as kind & inclusive as you've been at Soltau! I hope to see you all next year!

Cost of Change in Forests & Deserts

Marko Bjelac — Tue, 01 Apr 2025 22:24:00 +0000

I have been watching Dave Farley's MSE channel, which prompted me to leaf through his book Modern Software Engineering. I read it a year ago, but as I leafed through it again I discovered I had penned thoughts next to some paragraphs.

Leafing through to find more interesting stuff which I hadn't annotated, I found this:

... Dan [North] described the difference between waterfall and agile thinking as, effectively, a problem in economics. Waterfall thinking is promulgated on the assumption that change gets more expensive as time goes on.

-- Chapter 4, Working Iteratively, Iteration as a Defensive Design Strategy, p.46

Dave goes on to explain how in this view, the core difference between waterfall and agile is the cost of change.

This is visually represented with cost/time diagrams (redrawn here with minor additions):

As the Waterfall model does not require any coding practices which keep the codebase maintainable, we get 2 effects:

Starting things from scratch is very fast, as we only spend time on coding the thing we need
Each change is more expensive than the one before as we do not "waste" time refactoring, writing tests or coding in pairs/mobs

This strongly reminds me of Beth & Kent Beck's excellent metaphor, the Forest and the Desert. When Beth & Kent talk about the Forest, they mention a much more relaxed working environment. There is no stress. Work flows naturally, with no overtime and no rushing. Developers have the time to rest, exchange ideas or invest in the practices which help keep things where they are (i.e. the Forest). It seems to me that the cost of change in the forest is constant.

Conversely, things are much more stressful in the Desert. As the cost of change is rising all the time, deadlines slip, rushing is ubiquitous and there is no time to do activities which would help alleviate these problems.

While working in the Desert is possible, and indeed much more common today, I strongly prefer working in the Forest. I like to rest in the shade.

Notes

I believe the effect is related to Martin Fowler's Design Stamina Hypothesis.

For another, also excellent, description of Forest/Desert, see Beth & Kent's talk at Øredev.

Cost-of-change diagrams re-purposed with permission from Dave Farley.

Cover photo by Alin Gavriliuc on Unsplash.

Emergent test pyramid

Marko Bjelac — Tue, 11 Feb 2025 20:44:58 +0000

Cover photo by Samuel Bourgeot

TL;DR

Follow the principle:

Test each thing at the lowest possible level.

Of course, do test all the things (interactions between things are also things).

This will naturally lead to a test pyramid emerging:

End-to-end (E2E) tests: Hard to write, slow & unreliable.

Acceptance tests: Describe features, hard to write without a framework, not so fast.

Unit tests: Testing small pieces of data processing code, easy to write, very fast.

This gets you to the sweet spot between just enough coverage, number of tests to write and speed of test execution. It also allows easier refactoring.

Introduction

Writing automated tests is hard. To make it easier I advise you to test before the code is implemented. This is also known as test-first development. Add a bit of thoughtful pacing & cleaning up and you get test-driven development. With a bit of experience with software architecture & paying attention to the ease (or lack thereof) of writing tests you get test-driven design.

All these are for another article, albeit related.

The test pyramid is a well-documented concept. The benefits are real. You can cover all or almost all functionality of your software with keeping tests to a minimum & at the same time allowing for lots of refactoring without breaking any tests.

Here's how to get there: When developing your software, take small steps and try to adhere to the principles described below. Always know where you are in the codebase and act accordingly.

I know, sounds mysterious. It isn't. Read on.

Onion architecture

The architecture of your system is going to impact your writing of automated tests. The Onion architecture is by far the best suited architecture for thoroughly-tested systems.

There are several variations of this and I warmly suggest you read this article which explains them all but also summarises the key points.

I like the name "onion architecture" best because the name itself hints at what the architecture looks like.

Here is a diagram of my approach to this architecture:

Only 2 test layers needed

This architecture enables me to have just 2 types (or layers) of functional tests:

Acceptance tests
Unit tests

There are also integration tests but let's ignore them in this article.

Here is a similar diagram, but with tests:

Acceptance tests

These tests have 2 main purposes:

Describe a feature
Verify all wiring between services and all their collaborators is correct

Unit tests

These are the widely known small & focused tests. They test only one class (sometimes just a function). The class ideally should not have any collaborators as this complicates tests with test doubles. They are very fast to execute, typically under 10ms per test.

A DB digression

In my variation of the architecture the database is included in acceptance tests. Queries contain business logic. Acceptance tests should capture behaviour since they cover whole features, not just interactions between classes.

However, notice that the DAO classes have low-level tests. These are similar to unit tests as they focus on small pieces of code with no collaborators. They are not unit tests "by the book" since they use the database. However, they function in the same way:

If someone breaks a query (which is likely since queries tend to get complex) we will immediately know where the problem is because the query's test will fail.
They enable us to test-drive SQL (or whatever query language is used). We could test-drive with a database & an SQL client, but this way we have a test as an executable document that the query does what it's supposed to. Also, some ORM libraries have their own abstractions over SQL and test-driving is only possible this way.

Conversely, notice that controllers are not covered by acceptance nor unit tests. This is because they don't (shouldn't) contain any business logic. They are glue code and should be tested separately (see last section of this article).

Top-down

While designing your software, always remember what type of code constructs are available and which you are focused on currently.

This architecture is perfect for a top-down development approach. The approach has the least cognitive load (i.e. it takes up smaller head-space).

For each feature:

Write acceptance tests which describe a feature
- do not focus on a particular class; acceptance tests should be separated from the app's classes by abstraction layers so they can focus on behaviour of the system
Implement service classes as needed, defining their collaborators & wiring them (piping input & output data between them to get the result)
Avoid implementing collaborators:
- externals (adapters, see diagram) should be interfaces or abstract classes to be implemented later
- internals (logic or DAOs) should be implemented with stubs (methods returning dummy data or better yet, throwing "TODO" errors)
Test-drive internals' implementation with unit tests
Wire the acceptance test to the SUT (System Under Test), that is - the service class
- write test doubles to implement externals (don't use mocking libs ... another article)
Work on all the pieces until acceptance tests pass

Repeat for next feature and so on.

A very important principle:

What can go down, should

Extract, extract, extract. Whenever you spot a piece of logic, arithmetic or data transformation in the service, try to extract it into a class or function which can then be unit tested.

The number of execution paths through a service (counting only the service code, not collaborators) should be forced down to a minimum.

With that we can do this:

What can be tested down, should

Code paths going through a service's collaborators should be tested only in unit tests of those collaborators.

The only thing tested in acceptance tests should be wiring of collaborators.

The benefits

Benefit 1: Fast tests

By forcing most of the logic and testing down into the unit level, we maximise the amount of test coverage done by fast tests. Overall, test-coverage is not lowered but total duration of test execution is.

Benefit 2: Easy refactoring

By not having any tests between the lowest layer of unit tests & the highest layer of acceptance test, we make it easier to refactor services & their usage of collaborators.

Maybe a service has multiple sub-services which talk to units. Maybe one does and the other doesn't.

All this is subject to change as the developer's understanding of the system grows but also when the customer's requirements shift & evolve.

Refactoring is an activity which shouldn't modify functionality, so why should it cause us to modify our functional tests?

The 3rd test layer

Acceptance & unit tests do not cover deployment configuration nor the deployment process itself.

A 3rd test layer is needed. These tests are end-to-end tests. They are slow & tricky to write, typically testing through a web UI or a public HTTP API.

The good thing is, we need just a few of them:

After we deploy our app there are some things we need to verify to be sure everything works. These are marked on the diagram as red dots:

Is our app reachable from the outside world?
Did the deployment process successfully deploy the latest version?
Are configuration variables set to correct values?
- Like the ones used for connecting to the database, 3rd party & platform services.

These tests should be written after a new red dot comes up. Since the app should be deployed as soon as possible from the start of the project, end-to-end tests can be added continuously as the system grows.

They are of course ran against a deployed app on a testing or staging environment, the configuration of which needs to be as close to production as possible.

Emergence

The emerging test pyramid:

Unit tests: lots of them (counting individual methods, not classes) because we're covering all possible execution paths through units.

Acceptance tests: fewer, because we're covering one or two paths through a service

End-to-end tests: very few because we're covering only points of configuration

To be continued

This assumes only one piece of deployed software. What about apps with multiple pieces communicating through APIs? Doesn't that require more end-to-end tests to cover all the API communication?

No. Use API tests for that.

Engineering vs. crafting

Marko Bjelac — Thu, 06 Feb 2025 20:16:00 +0000

Cover photo by myself - my kids made holiday honey-cookies

Last year Dave Farley published a segment from one of his Engineering room interviews with Emily Bache.

It was somewhat provocatively titled:

What Is A Software Engineer? | Craftsmanship Movement Was A "Step Backwards"

Yet another scenario which goes like this:

a minority struggles to become a majority
everyone else ignores them
during the struggle the minority fractures and starts bickering amongst themselves, creating several even smaller minorities
everyone else ignores them even more

The minority I'm referring to are programmers (i.e. people making and modifying code for a living) who are doing their jobs with the highest level of quality possible. What is quality and what is possible are topics for themselves but this is the gist.

The programming-as-craft concept was more or less completely described a while ago by Bob Martin's post What Software Craftsmanship is about.

Dave's approach is that software engineering is not craft because it brings something else to the discipline. I have not figured out what. Software-as-craft does not imply the absence of TDD, BDD, continuous integration, deployment, delivery or any other "engineering-like" practice.

To take a step backwards (or rather, tilt our heads), what is art?

There are multiple definitions. Among those listed I think this one is closest to the context:

(countable) Skillful creative activity, usually with an aesthetic focus.
She's mastered the art of programming.

The examples gives it away I admit - programming can be art.

So can engineering.

This is surely art:

I'm sure most people will agree that this is also art:

However, there is a huge difference. Buildings also have a type of art seldom visible to most people. The building's structure & infrastructure are very complex feats of engineering. They required a lot of thought, planning, collaboration & quality of work which can be thought of as huge pieces of art. They are even more magnificent than a painting (or an architect's drawing) because they involve hard work & skill invested by a lot of individuals. My point is, categories are often fuzzy.

Programming can be art.

Programming can be craft.

Programming can be engineering.

Programming can also be none of the above. It can be a sloppy mess.

The important thing is that today most of programming is neither art nor craft nor engineering. It is a sloppy mess, hastily put together to meet a deadline and to make money quickly (mostly not going to the programmers themselves).

Here is a helpful diagram to paint the picture:

Instead of bickering about esoteric categories, we should put our energy and imagination to work on how to reduce the number of slop-pushers and increase the number of crafters and engineers.

SoCraTes UK 2024

Marko Bjelac — Wed, 25 Sep 2024 08:13:00 +0000

My colleague Ivana & I went to SoCraTes UK!

This is an unconference, meaning almost all things are unlike regular developer conferences.

But what is an unconference?

There is no schedule (up front)
There are no talks (there is talking though)
The amount of interaction with everyone there is through the roof

Here we go…

Glowing hula hoops

Before we leave for England, I browse the unconference github wiki pages and in the Arrivals page I spot a person named Corinna saying she is coming to London and would someone join her for the train & taxi ride to the event. I contact her through Slack, and the 3 of us meet in London & grab lunch together, after which we proceed to the unconference by train & taxi. We get to know each other & talk about our geeky stuff but also various other things.

In other words - we start the unconference even before we get there! 👍

The first day is informal. It’s a chance for introducing yourself, meeting people & chatting.

The unconference attendees are very diverse, but everyone is at ease and open to conversation. After the first dinner, Mervi performs a dance with glowing hula hoops for just a couple of us on a whim. Here is a trimmed video:

The diversity of the attendants is not a hindrance. It is rather the opposite - it brings richness & depth to the unconference because it is contrasted with a shared interest for software craft (and testing). In short, the interest for producing high-quality code and how to do it.

Open space

On Friday morning we attend the unconference opening session. We are (re)introduced to Open Space technology. In short, it is a set of guidelines designed to create environments which encourage collaboration.

It starts with a “marketplace” where anyone who wants takes a big-format post-it and writes a topic and their name on it. The topic can be something they know about or something they want to know about. Then all the people who have written a topic stand in line and one by one shortly explain to the crowd what the topic is about.

After you have explained your topic, you go to the adjacent room and you paste the post-it on the wall with a location-time grid so everyone knows where & when the topic will be discussed. This proves to be tricky for me because I don’t want to paste my topic at the same time of another topic that is interesting to me. But time & space are constrained so you have to make some decision here.


Friday sessions	Saturday sessions

If you have more topics, you move to the end of the line and on your next turn explain your next topic and so on.

At the end of each day there we reflect on the day’s sessions. This is again done in groups where each group discusses where they have been and what they have learned. Mingling among groups is encouraged in the same way as for all the other discussions.

These reflection sessions are a great idea because I find out what has been going on in the sessions I missed, I get to talk to people I haven't had a chance to talk to yet and they relax the crowd after the wind-up of the day, just in time for dinner.

Sessions

Here are descriptions of most of the sessions I attended.

Confidence in Software Engineers

Confidence is a complex topic. We do a lot of unpacking.

Confidence in presentation: not having the ability to speak or present your ideas with confidence, although you are confident in them
Confidence in execution: not having the ability to decide which way to go as you are not certain where you will end up

A feedback like “You have low confidence” is counter-productive and will lower the dev’s confidence even more. Be supportive & see who needs to change the most - the dev or her environment?

Also with gender taken into account, women usually appear less confident than men simply because men will “fake it until you make it”, having no problem to say they know something when they only heard a term once, while women will be honest about their experience. So, should women also fake it until they make it or should men stop doing that?

Another interesting perspective is that we value existing experience more than the ability to learn. The former is easier to measure, but the latter is much more important.

Problematic XP Practices

The central theme of the session is a list of contentious (often argued about) XP practices:

trunk-based development
pairing
monorepos
no estimates
no projects

Unfortunately (for me) most of the time was spent on discussing monorepos & no estimates. This depends on the crowd - that’s how Open space works.

I was most interested in the “no projects” topic. The gist is that this doesn’t mean projects should not be used at all. It means that developers shouldn’t set project-related goals, but instead should focus on the product. The product is much more important, while the project is just one of the tools to help product delivery.

How do you do BDD?

I suggest this topic in the morning. I hope I can gather various experiences and distill what are the core practices which make good BDD workflows.

This turns out to be one of the best knowledge exchanges I have ever participated in, as both Seb Rose & Nat Pryce 😍 join in and cut through the less-relevant stuff like tooling & syntax to the core of what is BDD. I try to capture it on a flipchart and annotate it that evening:

There are also my notes from the session on the unconference github wiki.

Android Java Mobbing

After all these “heavy thinking” sessions it is a bit refreshing to participate in a technical hands-on session. Anita has started building a chess game for Android in Java and she wants help with cleaning up the code.

We help her convert it to Kotlin, fix the build configuration & start on refactoring the code.

Stuff left for later is replacing the current presentation library with Jetpack Compose, and also separating game logic from presentation logic so it can be thoroughly covered with tests.

Remote XP

In this group we discuss how XP practices transfer to remote work.

XP has traditionally been designed around physical presence of all people required to do the work, so this is sometimes challenging when none of the people are in the office.

The discussions are in-depth so we only have time to cover 2 XP practices (informative workspace & sit together), but I remember these suggestions for remote XP:

The team dashboard will not be visible at all times (everyone having an extra monitor is complicated) so some alerting system can be put in place (Slack was proposed) so that everyone in the team knows when to look at the dashboard to see what has changed
- The team dashboard traditionally displays the current build status, but also any other information important to the current project
For solo work, a whole-day video call can be set up to which all solo workers connect. Although they do solo stuff, they can easily just ask anyone for help. The problem of spacial audio (you want to overhear a conversation, but not listen to it as you would in a normal call) software was proposed like Gather Town.
- I raised the problem of headsets being too hard on your ears if worn all the time. The response was that you should use the laptop’s speakers & microphone (even if it has less quality).

BDD reboot

This was a session organised by Seb Rose. It helped me put together all the bits & pieces I gathered from the previous BDD session but also from the last decade of my searching for a working BDD workflow.

I am pleasantly surprised to find out my team was almost on the correct path. We will try out some improvements though.

Testing UI components

Esko showed us how his team test-drives UI components. The approach is quite different than what I've used but the environments (client, requirements, etc.) are different so it’s hard to say whether our approach is really better. However, we do have interesting discussions about testing in general.

Example mapping

This is a workshop to plug the last holes in my understanding of practical BDD. It does not go as well as I expect, but still I’m glad to have tried it. Besides, I bought books on BDD in the morning, one of which explains example mapping so I’m confident I can pick it up from there.

The books are available on Leanpub.

Impact mapping

I suggested an Impact mapping session hoping several people were going to show us how it works in the real world. Alas, only one person from the assembled group did it 5 years ago. Nevertheless, they proceed to explain it to the whole group. I was surprised more people didn’t hear about it before but also at so many people attending the session.

Me showcasing my hobby project

A fun session happens when I offer to showcase my hobby project. It’s made using TDD & it’s a game. Both of these things cause interest, and I get some good feedback about the game and my artwork.

Software ball ⚽

This was planned for Friday morning but ended up being moved to Saturday. This was great because I would have missed it otherwise.

This is a very geeky ball game where participants throw a ball to each other representing execution of a program. The participants and the game facilitator try to agree on a set of instructions for each participant (a “node”) so the ball will travel according to the specifications with as few instructions as possible.

I liked it very much as it’s both fun, challenging & encourages physical activity in the open.

Other sessions

Time-space constraints being what they are on Earth, I missed most of the sessions. However it was clear that the session topics were very diverse. From autism & imposter syndrome through clean code practices all the way to specific hands-on tinkering with Excel, Bash, build scripts etc.

There were also many other discussions during meals, walks, drinks & evening board games. We were talking to each other a lot, since we were all together from 8-9 in the morning until midnight or even later.

Playing TDD, the board game. Yes, it was very late. 😜

Afterglow

During the unconference retrospective Mervi thought of the term afterglow to describe our state after the unconference due to the fond memories we created together.

In the days & weeks following the unconference I’m sure I’ll be buzzing with ideas & thoughts.

However, I think I will also be reflecting on the experience of the interactions I had, the kindness, curiosity, inclusivity & warmth.

I am deeply grateful to all participants. Thank you for the afterglow! ❤️

TDD is cheaper

Marko Bjelac — Thu, 11 Jan 2024 23:47:00 +0000

Cover image: Scene from Modern Family, Phil: "Slow is smooth & smooth is fast!"

Tim Ottinger posted this article: Do They Hate Writing Tests?

As always, concise & to the point. I had the same experience with all 3 types of code: Old legacy, new legacy & test-driven.

What I found very revealing in the article is this list of new-legacy activities:

Write a bunch of code (being very careful, of course)
Edit it until it will compile.
Debug it until it gets the right answers.
Look it over for other errors and correct them.
Send it off to code review

Here is what I think the TDD list of activities looks like:

Test-drive the code (no need to be careful, tests watch your back)
~~Edit it until it will compile.~~ for TDD-ers working in compiled languages, compile fail is a failing test, so we don't have more than one line compile failures and we fix it immediately
~~Debug it until it gets the right answers.~~ we test-drive, so bugs are few and far between (like, maybe 1 per month or less)
~~Look it over for other errors and correct them.~~ no need no errors - all tests ever written are run often (faster ones more often) so nothing is broken for more than a couple of minutes
Send it off to code review ... sure, we can do that (but check out Refinement Code Review by Martin Fowler)

Ah, sorry, I'll remove the superfluous items:

Test-drive the code
Send it off to code review

Hmmm, this list seems smaller than the new-legacy list. Could it be that ~~writing code using TDD~~ designing your system driven by tests is more efficient, thus cheaper? Remember, the most expensive thing in IT is the developer hour.

I've heard first-hand accounts of TDD projects being FOUR (4) times as efficient as non-TDD projects.

Granted, TDD takes practice, but doesn't everything?

Github Actions output to if expression

Marko Bjelac — Tue, 19 Dec 2023 22:55:02 +0000

Cover photo by Wim Arys on Unsplash

I wanted a CI pipeline job to fail if some numeric output was larger than 0.

The pipeline is set up in Github Actions and the job has a step which has a numeric output. I just had to give an id to the step to be able to reference it's outputs with Github Action contexts like:

${{ steps.stepId.outputs.outputName }}

The next step would check the output value, compare it to 0 and exit 1 if it is larger. Then I remembered steps (as well as jobs) have an if section which takes in an expression. I knowe you no longer have to put ${{ & }} around the expression but I wasn't sure if it would work simply like this:

if: steps.myStep.outputs.myOutput > 0

When I'm not sure of something, I like to test it. I often test pieces of Github Actions by making a new workflow, pushing it to master and trying it out on Github.

Here is my workflow for testing how can a job's step output be used in an if expression of a subsequent step:

I wanted to test it with different values so I used workflow_dispatch's inputs to give my workflow a custom parameter for testing.

I ran the workflow with several numbers and confirmed it works.

I also found the answer on the Github forum, but it would have been nice if Github Actions documentation had some easy-to-reach example for this.

I could have also probably gotten the answer even faster from an LLM prompt.

In any case, it is nice to be able to test your code, wherever you got it from.

Edit: When you have your test workflow, no need to push it to master & test it on Github. You can use act to test Github Action workflows locally.

JS Date: The Timezone Tantrum

Marko Bjelac — Mon, 13 Nov 2023 22:44:44 +0000

Cover photo by Lucian Alexe on Unsplash

Why

We had a subtle bug in our UI code which involved the wrong time offset being applied when date & time were input around the DST change.

Without going into the ghastly details, the underlying cause was we used the dreaded JS Date.

In our defence, we had to use it as it was the output type from a 3rd party widget.

At Software Sauna, we like to test stuff. Much more than that, we like to test stuff in isolation. We believed we tested our component in isolation, until we learned that JS Date is coupled to the OS.

We could control the DST flip by setting the test's input time to the appropriate time of year (summer/winter). However we couldn't control the timezone. We had to adjust the expected data in the test 🤢 using the same library which the production code used (momentjs).

How would it work on CI? - we asked ourselves. Well, even better, CI is always on UTC so it wouldn't be bothered with it.

After some thought we concluded this was a bad thing. If users' browsers were in a timezone, so should the UI tests!

We needed to set the timezone to our UI test CI job!

How

Thankfully, since we use Github actions for CI this was just a matter of finding an action that suited us.

We set up Sze Ying's action set-timezone and that's it!

Note: Only the UI/frontend tests job should have this. Your server should be in UTC and so should the backend tests job.

Frontend/backend contract testing

Marko Bjelac — Fri, 10 Nov 2023 09:00:00 +0000

Cover photo by israel palacio on Unsplash

Context

Contract testing is a known concept. It is nicely described in the Contract Tests section of the excellent article "The Practical Test Pyramid" by Ham Vocke.

Takeaway points:

Test consumer & producer together
Test only the contract layers, without the behaviour of either the consumer or producer

At Software Sauna we developed a similar approach, albeit with some modifications to fit our own flow of developing web apps:

We do not test on the HTTP layer - tests interact with a domain-specific layer which hides the data transport infrastructure (here called API functions).
We do not setup test-double behaviour on the producer side. Rather, we expose test utility endpoints and drive test double behaviour from tests directly so both input & expected data are visible in test.

The web app

Software Sauna predominantly produces web apps & not distributed systems, so most of contracts we deal with are those between the web UI usually called frontend & the behaviour & busines logic of the app usually called backend.

The frontend communicates with the backend by sending HTTP requests.

We want readable & maintainable code, so we slice our frontend & backend codebases into abstraction layers. This results in seams throughout the codebases, enabling us to have tests on relevant scopes.

One such seam is between code that implements behaviour (does stuff) & code that deals with HTTP communication.

Now we can look at the frontend's API-related layer, the HTTP channel & backend's API-related layer as a single component - the contract.

The contract has one responsibility, that is to transfer data from frontend to backend & back.

However, other things related to this communication are also part of it, like authentication, authorisation, throttling, etc.

Here is an example of a web app stack with the contract components in more detail:

To test the contract, we just replace the frontend & backend behaviours with tests & test doubles, respectively:

Example test

Every API test has two parts:

Frontend test
Backend test double replacing the actual service

The test in the example tests the API function getUsers(), which will be called by components who want to display a list of the system's users.

Test

Line 9: Log in as a specific user. This tests both frontend & backend authentication implementation & config. It is practical to create a single dummy user for each user role in the app.

Line 16: Stub the method labelled get-users with some test data.

Line 18: Call the API function which should result in a method call to the appropriate backend service (actually test double).

Line 20: Assert that the stubbed data is returned from the API function.

There is also an example of an unauthorised call to show that we can test the backend's authorisation config.

Test double

This example uses Spring to auto-wire services (actually, their test doubles) into the DI context.

The method labels (as string parameters in the withMethod calls) have to match string parameters in frontend-side calls to setStubbing & failWith. If they don't, the tests will fail.

Spying

Sometimes we want to know if the desired arguments were passed to the backend method.

Our backend test double acts both as a stub and a spy, enabling the frontend test to check returned values & also check that the correct arguments were sent.

Other stuff

Testing error handling

Similar to stubbing values, we can tell the backend test double that a method should fail. This allows us to test:

backend mapping of failures (i.e. exceptions) to HTTP error responses
frontend handling of errors

Part of error handling was already shown in the example for unauthorised calls.

Test-driving the API layer

This approach allows the API layers to be implemented within a TDD workflow.

We test-drive a UI component. The component requires data from the backend. As this is crossing the seam, we test-drive the implementation using a test double to replace the API function.

That test double defines the API function signature.

Then we can test-drive the API function itself, by providing a test-double on the backend side, which in turn defines the service method signature.

Conclusion

During our usage of this pattern in Software Sauna, we have found that it completely eliminates common errors like request/response structure definition discrepancies, but also harder to find errors buried in URL path & header definitions, error handling, authentication & authorisation setup.

Give me 0.5x developers or give me death!

Marko Bjelac — Sat, 11 Feb 2023 23:36:00 +0000

Slow is smooth & smooth is fast.

How does one become a 10x developer?

Here's ~~my opinion~~ the Truth:

Mikey is a 10x developer. Mikey is that guy who started the project. He knows every little detail, architecture decision & helper method. The entire codebase fits in his head. He started in Heaven, i.e. working alone. Unfortunately software is too big these days & time is money so his boss hired more developers. To work on HIS code. Mikey is trying his best to hold the code together, gatekeeping left & right (he's the pull request reviewer), making sure his vision is kept pristine & unsoiled. The other developers can't onboard as fast as the boss wants. They don't know their way around the code nearly as well as Mikey does. The boss says Mikey's churning out 10 times more stuff than them. They're helping but thank goodness we have Mikey on board - a 10x developer who is saving this project.

This is a myth. Mikey appears fast because he started the project, or has been so long on it he might as well been there from the start. Mikey takes shortcuts. Mikey rushes stuff. This makes him appear even faster. However, this is only good if you want to keep Mikey as the single developer on the project. New people take time to get acquainted with the code, with Mikey's decisions, patterns & conventions. Worse, since Mikey took many shortcuts, the codebase is convoluted & unreadable. There are no tests. Mikey refactors seldom if ever ("Gotta churn out those features!", "Have no time to clean up now, I can always do it later..."). Other developers either take their time putting things in order, writing tests & refactoring, or don't take time for this, instead trying to churn out features, breaking things & fixing them - taking even more time.

In reality, Mikey is probably as good as any other developer (all of us are) not better or worse. Churning out rushed code alone for a long time warps Mikey's mind & he becomes stuck to his codebase, thinking this is the best there can be. Mikey develops a blind spot and can't see he's slowing down. Mikey is slowing down because he's breaking stuff all the time, or having trouble putting in features which use existing code (often just copy-pasting the code & modifying that).

The charade breaks down when you put Mikey on a different project or confront him with lack of built-in quality in "his" project.

So, what to do?

How do we develop software without getting caught in a code quagmire?

The solution is absurd: 0.5x developers

These guys are 2 times slower! How's that gonna help?

Well, they're slower because for every line of feature code they write, 3 lines of test code goes in. For every 5 minutes of typing, another 5 minutes goes into discussion with their team mates.

They squander engineer hours (i.e. the client's money) on setting up continuous delivery pipelines, architecture & test patterns, attending exploration testing sessions, writing acceptance tests before the first line of feature code is even written & insane stuff like that.

They're slower. Because they take the time to make their work smooth. Which in turn makes them faster.

For every test not written, skipped refactoring or good practice ignored, there is an undeterminable length of time waiting silently in some dark corner of the project's uncertain future. Time spent in debugging, reworking existing code or just plain bashing one's head against the desk.

No, I say give me half-x developers. They're faster.

Proud to be a Grug

Marko Bjelac — Wed, 04 Jan 2023 00:36:00 +0000

This is a review of an article (calling itself a guide, or is it a manifesto?): The Grug Brained Developer

First off, I agree with a staggering majority of statements!

Also I highly applaud it's writing style (hello Pygmy) - the broken, stripped-down 1sentence=1paragraph English makes it strangely more readable than most IT texts (or maybe it's very late).

I broke this down into three parts:

✅ I like 100% for things which ... I like 100% with short explanations why
🤷 Neither here nor there for things which I think the author didn't clearly state their position on or possibly I didn't understand it
🫤 not 100% for mixed stuff which I have serious doubts about and I dig into it

Let's go.

✅ I like 100%

Complexity in no unclear terms asserts that "complexity spirit demon" is bad. That's it. 100% correct. No point in musing about accidental vs. intentional complexity. It's all bad.

Saying No & OK are very nice descriptions of the ideal & realistic tools to handle the complexity problem. I like the 80/20 (although don't take the numbers seriously) rule & especially not dumping the entire truth on non-techies.

Factoring, aside from the nice touch of accuracy in calling it factoring without the superfluous re, has very valuable advice in not taking it too far - you don't yet know in what direction the code will go and you're in danger of factoring yourself out of readability.

Similarly Refactoring and Chesterton are very nice, although I have a feeling the author separated "factoring" & "refactoring" to two pretty different contexts (improving code locally & globally, respectively) the examples (J2EE & OSGi) & advice are dead-on.

Microservices tells it succinctly, reminding me of the question: If you can't factor your codebase properly, what makes you think putting network calls in the mix will improve things?

Type systems section is a nice warning to not go too far with them. We're not researching new branches of maths here, we're trying to build software.

DRY is explained very well, also closures, concurrency & optimising, all of which are aspects of tackling complexity which can get out of hand (i.e. become complex themselves).

APIs section is OK, albeit a bit specific while being unclear at the same time. Is the author not happy with Java APIs? So is this author! Switch to Typescript & Kotlin! 😉

Parsing is also touched upon in this (apparently very broad) guide. I almost put it in Neither here nor there, but gave it a 2nd read and liked it: Basically, complexity is the enemy (again). Keep it simple.

In the end of the guide, fads, FOLD & impostor syndrome are pretty accurate descriptions of issues in developer psychology.

🤷 Neither here nor there

The bit about Agile has nothing really of note ... The Agile concept has a lot of potential. If done right it can completely transform people and companies they work in for the better. Tech practices like automated testing (and test-first practices like TDD) can seriously help in this.

Separation of concerns is in my view misrepresented by an erroneous example of separating HTML, CSS & JS while the proposed solution (Locality of behaviour) is actually what SoC is. So, we basically agree on the principle but not the naming which I don't care about anyway.

The visitor pattern has only "bad" with link to the Wikipedia article, so not much to go on here ... for what it's worth, I don't see much use for the pattern in modern languages and architectures.

The section on frontend development reminds me of a simplified take of a mostly-backend developer. Today's frontends are apps in themselves & and their complexity is simply the result of mounting user expectations arising from explosion of app users with the majority of them being quite non-tech.

🫤 not 100%

In the Testing section I like the non-mocking part.

Also I kind of like & agree with the "small, well curated end-to-end test suite" + "integration test sweet spot" if by "integration tests" the author means deployable-level (backend-only, frontend-only) acceptance tests which don't focus on implementation details but on behaviour.

However, using them with a lot of debugger action is just a sign of missing unit tests (which is clear from the other parts of the section). Having good unit tests (and lots of them, especially on backend, which the author is apparently at home in) is a life-saver when writing acceptance tests since the acceptance tests can also be narrow and focused - as they should, since they're harder to write and slower to execute.

Tools is basically a call for debugging. To me frequent debugging is a sign of missing unit tests (see previous paragraph) and shows room for improvement in your testing strategy.

The Expression complexity section is just a specific example of an "optimise code for debugging" strategy, although the specific "good" example strikes me as more readable than the "bad" one. Nevertheless, I wouldn't recommend optimising your code for anything other than readability.

Likewise, logging is also an example of trying to improve things where unit tests (and possibly "integration" tests, or rather acceptance tests) are lacking. A well-tested deployable has to have logging only for input & output traffic. Logging "all major logical branches within code (if/for)" is just crazy.

Conclusion

I like Grug. They're headed mostly in the right direction regarding principles and mindset. Unfortunately, automated testing is hard to get right but when you do the payback is more than handsome!

How to run your tests with a single keystroke

Marko Bjelac — Wed, 09 Nov 2022 23:34:42 +0000

Photo by Johnny Briggs on Unsplash

Why?

What is the point of going through the trouble to set all this up? I will try to briefly explain the reason I like to set up my test runs in this way.

Test-driven development

TDD is a practice which has many variations. The canonical "red, green, refactor" variation is an oft quoted one:

Red: Write the tests, they fail (compile fail also counts)
Green: Implement the code which the tests test, tests pass
Refactor: Clean up the code (both implementation & tests), presumably running the tests again to see if you broke something while refactoring

This is a very short & simple description which doesn't get into details, some of which can be important. One of which is the prediction step:

1a. Red: Write the tests
1b. Red: Try to predict the result of their failure
1c. Red: Run tests
1d. Red: Compare the actual failure result to your prediction
1e. Red: If they differ, either fix your understanding of the tests or fix the tests

There are other variations including or excluding this one.

In general, I find that if the developer writes code with tests (before, after or in-between), this is enough to get the test-driven benefit: The tests guide the code/design leading to just enough code being written in a readable, decoupled manner which makes it easy to understand & modify.

Time

To get this benefit, time is of importance. The time window within which both tests & implementation are written has to be small because the human short-term memory can hold only so much information and for a finite, often short, amount of time.

This leads to two requirements:

Your tests have to run very fast
You have to run your tests often

Writing fasts tests is a skill to be practiced & perfected but is out of scope of this article. However, I assure you it is possible to do, even for higher level non-unit tests.

Running tests often is easier to do when the process of running them is simple. The simplest process I can think of is a single keypress.

How?

In this part of the article the theory ends and practice begins. The example is very specific and I leave it to you to extract the principles and apply it to your set of tools if needed.

We will be using:

Intellij Idea
Intellij plugin Run Configuration as Action

1. Create a test configuration

Create an Intellij Run Configuration to run your tests.

Try it out - run it by selecting it in the Run Configuration drop-down menu and clicking Run button.

When you're happy with it, give it a nice name you'll remember, like unit tests.

2. Configure action keyboard shortcut

Go to Preferences / Keymap / Plugins / Run Configuration as Action.

Scroll down until you find an entry Run 'unit tests' (you may have to restart Intellij for it to show up in the list).

Select it, right-click and choose Add Keyboard Shortcut.

Enter keyboard shortcut, i.e. F10. Sort out any conflicts how you see fit.

Press your shortcut to see if the configuration runs.

3. Diversify

On a more complex project (e.g. multiple stack layers of a web application) there can be multiple run configurations for varying types of tests. Create each one with a different name and set up a different keyboard shortcut for each.

Examples:

F10 Backend unit tests
F9 Frontend unit tests
Ctrl+F10 Backend integration tests (testing adapter code with external services)

This way you can selectively run only one type of tests, according to the part of your system you are working on.