DEV Community: Sergei Cherkasov

One Branch to Rule Them All

Sergei Cherkasov — Wed, 19 Aug 2026 16:09:22 +0000

Hey everybody. This is Mikhail, the technical lead of the Axelix project.

For quite a long time I wanted to write a small article outlining our git branching model, in hope it may be useful to other people.

There are quite a lot of git branching strategies in the world, e.g.

Gitflow
GitHub-flow
Trunk-Based-Development (TBD) and so on.

Throughout my experience I can tell, that teams usually do not adopt the given strategy in the exact form/shape, rather, they either invent something completely
new themselves, or they just take, for instance, aforementioned GitFlow and modify it for their needs.

So, throughout already a year of development of Axelix, we have adopted a slightly modified Trunk Based Development model, and I think it served us well.
I hope you will find it also useful. This model admittedly has certain downsides, but in general, we're happy with it.

Before we start, you should be mindful of the requirements we tried to address. At the end of the day everybody must judge for themselves.

Small Prerequisite. Axelix Versioning.

The two most difficult problems in software are naming and versioning.

This is not the exact quote, but it is a rough sense of the joke that Thomas Wuerthinger (GraalVM Project Lead) said on BoF on Devoxx Belgium 2025 (explaining the "Detaching GraalVM from the Java Ecosystem Train" article).

To later understand on why we're doing certain things we're doing, it's going to be useful to realize the versioning scheme we're using.

At Axelix, we use semantic versioning of our components. I'd even say that SemVer is a de-facto standard for versioning the modern world. There are, of course, simple versioning schemes, like for Windows OS, when you
have Windows 7, 8, 10 or 11. There also is software that is released under the different variations CalVer. The JetBrains IDEs will be a good example of that,
e.g. 2026.1 or 2026.2.

Still, the majority of projects do SemVer, and Axelix does it as well. But when we're talking about the modern software - it is often composed of multiple components.
For example, Axelix has:

Build plugins for Maven/Gradle
Spring Boot starters
Master as the separate bootable JAR
Docker image of Master
Helm Chart of Master

So, the thing is that each of the points above represent an independent artifact that is generally distributed independently of others, and thus, it has its own coordinates.

And in our case, we have selected to follow the Lockstep Versioning of the Axelix project. In short, this is not the versioning schema, but a versioning strategy where all
components of the system share the same version X.Y.Z. It means, that if we release Axelix 1.4.2, all the components above receive the same version - 1.4.2.

Yes, we know that Lockstep versioning is generally a highly debatable subject for a couple of reasons. And I would say, that team should generally think twice before adopting it.
I should probably write another article outlining why we choose semver with lockstep, and why it may be a good idea for some of you as well. But this is an off-top for this article.

The Problem

So, you're starting a new project, or you're about to revisit the git branching model in your team for various reasons. When you try to implement any technical solution (let's say, you want to choose a git branching model for the project), it is generally a good idea to take a step back and answer the question:

What exactly is the problem that we're solving?

Indeed, before explaining anything, we should first realize what are the specific requirements that we want to address with any git branching model. And these requirements
will be different for different kinds of software that has different release cadence. In the case of Axelix, we wanted a branching model that would:

1. Give us the ability to do patches

We want to be able to deliver patches quickly.

Moreover, the important thing is that we do not know the amount of patch releases in the given minor in advance. The general
requirement is to be able to go to the arbitrary minor release, and apply an arbitrary number of patches for it (for example, to fix the CVE).

2. Avoid the merge hell.

A lot of git branching strategies easily end-up in the merge hell, e.g. GitFlow is infamous for ending up in such conundrums.

So, with that in mind, let's finally discuss what branching model we actually adopt.

Axelix Git Branching Model

At Axelix, we have the monorepo. And in this monorepo we have the main trunk, called 'master' trunk (the thing we borrowed from TBD). Some commits that do
polishing or basic housekeeping happen directly in the master trunk. For features, we create short-lived branches (directly from master) that gets merged
back into the master trunk:

In some extreme cases, adepts of TBD advocate for no feature branches at all with the risk of them being long-lived, and I understand the rationale behind it.
However, for OSS projects such as Axelix, we cannot allow for that because of external contributors and for various other reasons.

Nevertheless, feature branches ideally need to die fast. To facilitate "the death" of feature branches, we impose a couple of rules on the feature
branches, and famously, we introduce a cap of 500-lines PR. In other words, feature branch cannot contribute more than 500 lines of code into the main trunk (there are some
exceptions to that rule, but it does not matter right now). This cap ensures that:

The PR is small enough to be carefully reviewed.
The feature branch will indeed be short-lived, since the smaller PR the faster it will be ready for review.

It is generally well-known that for small PRs the overall TTM (time-to-merge) is smaller,
and the cap ensures feature branches die fast and they do not evolve into the long-lived branches. So here, we're perfectly aligned with the TBD.

When we want to perform a minor/major release, we create a tag on the master trunk of our monorepo and execute the release pipeline (very simplified):

Since we have the monorepo with the lockstep versioning, this tagged commit is the one from which all the release artifacts are built. And the value of the
tag is the version that Axelix release gets.

If we want to do the patch release, we create the branch from the git tag, e.g. a branch named 1.0.x. That is the long lived branch that is going to live by itself.
Once we have created necessary patches in the 1.0.x branch, we create a tag in that long-lived patch branch, call this tag v1.0.1 e.g, and release it then:

And here the pivot point where we significantly and deliberately depart from TBD. In TBD, it is forbidden to have long-lived branches apart from the main trunk.
But I want to take a step back and explain not what is forbidden, but why TBD advocates against it, and why it is okay in our use case.

TBD: Why patch-branches are okay.

TBD is a well-known and proven git branching strategy. It is adopted by Google, Facebook and other companies.
And it does not allow long-lived (apart from the main trunk) branches for a variety of reasons. One of them, and, probably, the most notorious is the merging problem. Merging the long-lived branches is quite challenging and time-consuming,
error-prone, bug-welcome and so on.

This problem becomes real in scenarios, when we develop certain functionality, that is intended to be later merged with something else, like a main trunk. But in case
of such patch branches, we do not intend to merge them ever. They are not supposed to be merged.

According to SemVer, the changes that go into the patch releases are (very broadly):

Backwards compatible bugfixes
Backwards compatible perf. improvements
Backports of CVE patches

Of course, we can discuss all day what exactly backward compatibility means, whether it accounts for "behavioral" backwards compatibility or source-level backwards compatibility and so on.
Let's put that aside.

The core idea is that patch branches will never have any kind of features developed in them, that are going to be merged back into master trunk. That just won't happen.

In our case, for example, the changes that end up in the patch branches are the very specific commits that just got cherry-picked from the main master trunk.

Challenges & Problems

Of course, such a model as above has challenges. There are a couple of them. Let me enumerate them.

1. Minor/Major Dilemma

One of the most important challenges of such architecture is its Minor/Major inflexibility.

So, what do I mean by that?

Well, for example, let's say, that you're developing version 1.7 of your software. And now, you're thinking about releasing a new major version, 2.0. If you're
making that decision, you're effectively starting to merge all the changes that you wanted to end up in the new major (e.g. non-backward-compatible ones, more on them
later) into the master trunk. Well, once you've started doing that, pivoting back and saying stuff like:

Oh, no, we changed our mind, we just want to release 1.8

It becomes really hard, in some cases infeasible. That is the inflexibility I'm talking about.

Still, that problem (in its various levels of severity) of having no simple return follows a lot of similar git models, TBD included.
So, in the industry, this problem is generally a consequence of the trade-off of not having merge hells.

2. Long-Lived Breaking Changes Branches

Well, when I said to you, that we have master trunk and patch branches as the only long-lived branches, I have omitted one thing. One very important thing.

And that is: our git branching model allows for long-lived feature branches that contain breaking changes. And since such branches are intended to be
merged, we have to postpone them until the next major (at very least). And if we combine that with the problem above, then we realize - we're in trouble.

Well, although we are in trouble, the degree towards which we're actually in trouble is debatable.

First of all, it significantly depends on the fact of what changes we consider breaking. And for every
mature system such changes may be different. In our case, we have a whole documentation page that explains our release cadence and overall breaking changes
impression.

Another thing is that we can try to mitigate such problem by constraining the amount of breaking changes subject for the next release. It is not always
feasible/predictable, but tackling that problem not from a technical, but from an administrative PoV may also help here.

So, admittedly, this is also a challenge that we have to live with. We may try to mitigate that, but to some degree we're going to have it.

Conclusions. Axelix, Lessons Learned.

So, again, I did not want to say that we have invented some astonishing or mind-blowing git model. Internally, we just felt that it may be worth sharing with
the world the git branching model we adopted and the reasons why.

The goal of the article was more to outline the way we approached the problem with the hope that you'll learn from it. Axelix has the Open Source core,
so if you want to learn more - you're welcome.

Remember that there're always trade-offs, and sometimes it is okay to diverge from certain well-established practices. Still, you always have to
clearly justify such divergences and, what is also important, realize the weaknesses of your solution as well.

Take care!
Mikhail

Axelix goes GA. A journey of a thousand miles begins with a single step

Sergei Cherkasov — Tue, 11 Aug 2026 12:39:57 +0000

On behalf of the core Axelix team, and everybody who has contributed to the community, I want to declare: we finally did it.

Axelix, finally, goes GA (Generally Available)!

For those who do not know - Axelix is a product with an Open Source core, that allows you to discover the common problems, pitfalls and inefficiencies in Java applications at large scale.

We're available on GitHub (btw - give us a star!).

In this post, I want to share the story and the motivation behind the product overall. I hope you find it interesting.

The Story. Big "Why" Behind Axelix

Java is quite an interesting language and ecosystem in general. I think a lot of people will not argue that it is quite old, and it was one of the first so-called "Object-Oriented" languages, that actually gained massive adoption. It both was, and it still is the backbone of modern enterprise.

For anyone who claims that Java is dead - I recommend checking the JetBrains State of Developer Ecosystem survey or even the Stack Overflow survey for 2025 (and Stack Overflow has, sadly, become a part of history). It is clear that Java as a language and the "ecosystem" around it (including Kotlin) is still relatively popular, and it remains true.

Ecosystems around Languages

The experienced developer knows that today's ecosystems that evolve around languages are typically very diverse. For example, let's talk about JavaScript. If we decide to run JavaScript on the server, then we're probably going to work with a database of some sort. Therefore, we're also going to need a framework, a library to work with the database, e.g. an ORM (I know that we may work without it but let's leave that aside).

And in JavaScript, we have quite a lot of options:

Prisma
TypeORM
DrizzleORM
Kysely and so on.

We can pretty safely state that Prisma ORM is probably the most used ORM on JavaScript. But notice that it is far from being the definitive JavaScript ORM.

It is not like Prisma is the default choice and is by far the most popular ORM - it is just not the case. I want to emphasize - even by Prisma's own assessment of its popularity, it is not far ahead of its competitors. They are all very close. So, the way people work with the database in JavaScript may differ heavily from team-to-team.

The defining trait of Java Ecosystem

In Java, if we're going to take the same problem (working with the database), then we will quickly realize, that the industry is heavily concentrated.

We generally can state that Spring Data JPA as a solution around Hibernate occupies above 50% of all the data access solutions, let alone ORMs. I remember some time ago Josh Long, the much-loved Developer Advocate for Spring, posted a survey on X (formerly Twitter) about the data access technologies usage:

// Detect dark theme var iframe = document.getElementById('tweet-1528655715933597697-638'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1528655715933597697&theme=dark" }

We must of course acknowledge that there are fast-growing alternative solutions to JPA that are explored, such as jOOQ, but Spring Data JPA dominates the field. So, the way we work with the database in Java (at least on the server side) is relatively well-defined and revolves around Spring Data JPA.

But there is more to it, it is not just the ORMs or data-access libraries. It's something bigger.

Spring Framework as the Phenomenon

We cannot talk about Java ecosystem and not talk about Spring Framework. If we're going to look in the aforementioned Developer Ecosystem State report from JetBrains, we're going to get the following insights. I have assembled them carefully for you - share them freely as you want. Also note that the respondents had multiple choices:

Framework	Users	Share of framework users
Spring Framework	3,042	87.8%
Ktor	362	10.5%
Quarkus	287	8.3%
Other	210	6.1%
Vaadin	104	3.0%
Micronaut	95	2.7%
Grails	61	1.8%
Helidon	36	1.0%

This is (at least AFAIK) one of the most recent and most trusted data we have. Many thanks to JetBrains for publishing it.

So, yes, although other ecosystems are also growing, e.g. Quarkus along with its Quarkiverse, but they still have a very, very long way to catch up with Spring Framework. So at the end of 2025 (I wager that even today) we can safely state:

The most common Java app, which by far represents more than half of Java server side deployments is a Spring Framework app.

Again, it is just data, you can download it and check yourself.

But even if we consider different ecosystems: Spring Framework, Quarkus or Micronaut etc - we're going to quickly realize that these are not just "libraries" or "frameworks" in a traditional sense. They are themselves large frameworks that build an entire sub-ecosystem around them. For example, are you working with Data? Well, you have

Spring Data in Spring
Jakarta Data in Quarkus
Micronaut Data in Micronaut

Oh, you want to send an HTTP request? The most common thing on the backend! Well, we have:

Spring Cloud Exchange/OpenFeign in Spring
RestClients in Quarkus
Declarative HTTP Clients in Micronaut

Notice that every framework has its own solution.

In other ecosystems, e.g. in JavaScript on the server side, we may use:

ExpressJS for web server
Axios for sending requests
Prisma as an ORM

And these are all just individual choices made by the team. We may use Axios or we may use Got. We may use Prisma or we may use TypeORM. Some solutions are more popular than others, but they are all independent - they exist outside of a single umbrella, like Spring Framework, for example.

To put it simply:

In the Java world, if we have any kind of problem, most likely, we do NOT need to seek the solution on GitHub, find some fork that does what you want (which is a common JavaScript practice btw). There is almost 100% chance that Spring Framework has a solution for us already.

Why am I telling you about this?

Because it is important to understand, that since Java Ecosystem is so solidified around the Spring Framework technological stack, it often suffers the same problems in production.

What are these problems? Well, there are a lot of them. And we know all of them with our very own butts:

Our connection pool leaks
Our API endpoints are performing slow (maybe the problem is in the database?)
We accidentally expose /actuator/env in production and leak secrets
Our applications consume too much memory and start very slowly...

And so on. And the industry, throughout decades of Java experience in production, has developed a set of recommendations, best-practices, "solutions", guidelines. And these guidelines exist on different levels of the application, e.g:

Guidelines for Hibernate/ORM

and so on. Guidelines for Spring performance:

Disable OSIV
Use Spring Test Profiler! (many thanks to Philip Riecks for such a tool)
Use Spring smart context caching! (Sergey Chernov, a highly experienced Engineer and a buddy of mine, developed the tool)!
Do not set spring.jpa.show-sql=true or other dangerous properties in production!

and so on. Guidelines for even our beloved Java!

For Christ’s sake, use Project Leyden!
Use Compact Object Headers (Project Lilliput)
Configure the logging of GC in production!

And so on and on and on. Because we have that solidified ecosystem we generally know "what is right and what is wrong". And for the long time there was no such tool.

But we thought that this is wrong. And we probably should have one. And this tool is called Axelix (The source code).

In 1.0.0, we do not support the detection of all the issues that I outlined above (most, but not all). And the above is just an example. There is a lot (really, a lot) of knowledge that we as a Java community have accumulated throughout these years that we're going to put inside Axelix, so it can serve you well.

I hope, at that point, the motivation behind the tool is clear, and now, I want to answer a couple of questions that we already have received many times over during Milestones.

Q: Is it free?

Yes, it is. We're going to follow the Open Core model. This is the Open Source software development model that underpins projects that we all love and care about:

Grafana
Keycloak
Vaadin

And so on. It is generally considered to be the most reliable model for the OSS development, and that is why industry leaders choose, and that is why we choose it.

Q: Is the project ready for use and deploy?

Yes, it is ready for use free of charge. We have processed the feedback from literally tens of teams that have installed Axelix milestone releases and shared their insights with us.

Q: Is it safe to deploy in production?

It is designed for production, so the answer is yes. But since this is the first 1.0.0 GA release, the general recommendation is to first install it on development environments, and then for production.

That said, we do have teams that deployed Axelix in production already to get insights about their @Transactional methods behavior and properties resolution.

Bottom Line: The core stays Open Source always, and it always will be free of charge, and it already provides value for the teams.

Where Are We Headed?

The team behind Axelix has many years of experience writing and optimizing Spring Boot applications. We have a lot of work to do ahead of us, and we still have a lot of things to incorporate into Axelix.

For those who want to know how the project is installed & configured, please, visit our website and also our documentation. In case of any questions or difficulties, you can always reach out to the team at: hello@axelix.io We, the maintainers, are happy to answer your questions and assist you during the installation.

We're also going to stay committed to Open Source, and committed to our values, which are making sure that your Java applications are as secure, performant and efficient as they can be.

Thank you all. Mikhail.

Taming Hibernate in Tests

Sergei Cherkasov — Sat, 08 Aug 2026 07:51:22 +0000

Hi everyone! This is Mikhail Polivakha, the technical lead of the Open Source Axelix project (a project dedicated to helping you identify common problems in Java server-side applications, including while working with Hibernate).

In this article, I want to address the question that I think is pretty common amongst the advanced Hibernate users:

"Is there a verify Hibernate behavior in tests (like Junit for example)?"

Here it's really important not to hand you a "fish", but to teach you how to fish - that is, to give you a framework of what's worth keeping in mind when working with Hibernate.

Controlling Hibernate during tests. Overview.

If I asked you: guys, which problems in Hibernate annoy you the most? You'd mention things like the sneaky N + 1, In Memory Pagination (when explicitly specifying setMaxResult or a Pageable), a Cartesian Product loaded into the application's memory, or, say, some baffling swarm of SELECTs followed by UPDATEs/DELETEs under the hood, and so on.

Everything I listed above, and really all "problems" with Hibernate, can be split into 2 categories. Let's break them down.

1. Problems at the ORM level

There are situations that both we (the end users) and Hibernate identify as problems. For example, up until Hibernate 7.4, the query below would perform pagination entirely in memory. This is fairly well known:

@Transactional
@Query(
    value = "SELECT o FROM Owner o JOIN FETCH o.pets",
    countQuery = "SELECT COUNT(o) FROM Owner o")
Page<Owner> findAllWithPets(Pageable pageable);

In version 7.4 Hibernate learned to do pagination within a sub-select. But nevertheless, if you, for example, work on Spring Boot 3, you have Hibernate 6, and in the case of queries like the one above there will be a warning in stdout:

HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory

And it's there because Hibernate itself understands that its actions may blow up your heap. There's even a property that we at Axelix recommend setting for new microservices that don't use 7.4 yet (and there are still many of those):

spring.jpa.properties.hibernate.query.fail_on_pagination_over_collection_fetch=true

If you set it, Hibernate will simply throw an exception where it would previously do In Memory Pagination.

In short, what I want to say is that the problem above is understood by Hibernate as a real problem. It recognizes and admits it. That's one layer of problems.

But oddly enough, these are quite hard to track. Hibernate rarely provides any means to hook into it (although there are some nuances, read below). For instance, at Axelix, to detect In Memory Pagination (if it happens), we simply literally catch an ILoggingEvent and inspect the code within it. Because there are no other acceptable ways (at least none that we're aware of)!

2. Second. Problems at the application level

There's a conceptually different layer of problems. N + 1, for example, belongs to it.

Let's think for a second: what is N + 1?. Try right now, without looking anywhere, to clearly formulate the definition in your head. Done? Here's how I'd formulate it (informally):

It's a situation in which you iterate over a collection loaded by Hibernate, sequentially accessing some lazy field within each individual entity of the collection, thereby triggering "N" additional SELECT queries.

That is, if you think about it a little, it becomes obvious that for Hibernate this is just Lazy Loading. The notion of N + 1 as a problem exists at the application level, not at the ORM level. That is, the problem is not lazy loading itself, but the semantics of lazy loading (what does this particular lazy loading mean? Is it just lazy loading, or lazy loading within an N + 1?).

In such a situation it's obviously pointless to rely on Hibernate, since the N + 1 phenomenon happens at the application level, and the ORM is completely unaware of it — it's not its area of responsibility. You can't get by without fairly strong tooling around Hibernate. Can it be written, and if so, how?

If we're talking specifically about N + 1, then the answer is generally - yes, you can, and we did it at Axelix in Open Source. Let me tell you how exactly we did it. The source code is open, take a look if you're interested.

The General Approach to N + 1 Detection

Hibernate doesn't know what N + 1 is, but it does know what a Lazy Loading association is, and that moment can already be caught. For example, here's how we do it in NPlusOneCollectionLoadListener:

    @Override
    public void onInitializeCollection(InitializeCollectionEvent event) {
        try {
            PersistentCollection persistentCollection = event.getCollection();
            EventSource eventSource = event.getSession();
            CollectionPersister collectionPersister = eventSource
                    .getPersistenceContextInternal()
                    .getCollectionEntry(persistentCollection)
                    .getLoadedPersister();

            LazyLoadingTarget lazyLoadingTarget = parseLazyLoadingTarget(collectionPersister.getRole());

            if (lazyLoadingTarget != null) {
                transactionAccessor.recordLazyLoading(lazyLoadingTarget);
            }
        } catch (Exception ignored) {
        }
    }

    // The general "role" format is expected to look like this: com.example.Order.items
    public static @Nullable LazyLoadingTarget parseLazyLoadingTarget(String role) {
        try {
            int separatorIndex = role.lastIndexOf(".");
            Class<?> ownerEntityClass = Class.forName(role.substring(0, separatorIndex));
            String propertyName = role.substring(separatorIndex + 1);
            return new LazyLoadingTarget(ownerEntityClass, propertyName);
        } catch (ClassNotFoundException | IndexOutOfBoundsException e) {
            log.warn(
                    "Unexpected propertyPath format '{}'. Axelix cannot recognize that, so lazy loading and potential N + 1 is not going to be tracked for this property",
                    role);
            return null; // it means that the role format is not the one that we expect
        }
    }

Here, through a series of manipulations, we can figure out which association was loaded lazily and on which collection. What do we then do with this information?

Axelix, for example, currently makes the following decision: If we noticed that within a transaction there were several lazy loadings of the same association, then we consider this to be an N + 1.

Is that always correct? Well, this is debatable, because, for instance, in this code example, if we assume that Order.items were loaded lazily — we, seemingly, don't have an N + 1:

public void compareOrders(Long previousId, Long currentId) {
    var previous = orderRepository.findById(previousId).orElseThrow();
    var current = orderRepository.findById(currentId).orElseThrow();

    // Two lazy accesses to Order.items, but there's no collection of orders here -
    // we're just comparing two specific versions of the same order
    if (previous.getItems().size() != current.getItems().size()) {
        throw new IllegalStateException("The order contents have changed");
    }
}

Or do we? And what if I change this example to something like this:

public void compareOrders(Long previousId, Long currentId) {
    var orders = orderRepository.findAllById(List.of(previousId, currentId));

    var previous = orders.get(0);
    // Exactly the same comparison as above, but now within an iteration
    // over a loaded collection of orders: at each step there's again a lazy
    // access to Order.items on both previous and current
    for (var current : orders) {
        if (previous.getItems().size() != current.getItems().size()) {
            throw new IllegalStateException("The order contents have changed");
        }
        previous = current;
    }
}

Does it look like N + 1 now? It does.

So, in short, what I want to say is that here you need to clearly fix the definition of N + 1 at the application level. We at Axelix deliberately decided that this case is nonetheless worth treating as an N + 1, so, in the UI, it will be reported to you:

P.S: Among other things, there's a small nuance here: N + 1, strictly speaking, can also happen without an open transaction when OSIV is enabled. That's a separate case which we're not considering for now, since it would complicate the picture.

Micro-Conclusion

I'd like to draw a small micro-conclusion here. In general, detecting some complex phenomena that occur at the application level while working with Hibernate:

N + 1
Blocking calls inside transactions, and so on.

This can be done. It just requires you to write a fairly large and non-trivial amount of tooling. Using N + 1 as an example, I hope you've roughly understood what such things will look like.

General Hibernate Problems

As a separate section, I'd like to address general Hibernate problems. Quite often people have some conditional hot-path for saving or updating data. And devs simply want to make sure that
Hibernate doesn't "sabotage" the entire process undercover. Sounds familiar, right?

Here you need to take a step back and ask: and what do we mean by "sabotage"?

Having talked with people, we'll discover that most often people want roughly the following: to have confidence that a person wrote repository.save(), and that it will execute specifically an INSERT into the table and nothing more.

For example, having this piece of code:

@Service
public class OwnerService {

    private final OwnerRepository ownerRepository;

    public OwnerService(OwnerRepository ownerRepository) {
        this.ownerRepository = ownerRepository;
    }

    @Transactional
    public Owner registerOwner(String firstName, String lastName) {
        var owner = new Owner(firstName, lastName);
        return ownerRepository.save(owner);
    }
}

The person wants to be sure that there won't be any hidden SELECTs and so on there. I think some people recognized themselves. Can this be done?

The answer: generally yes, it can. Hibernate has a Statistics API, which on the one hand isn't part of the JPA standard, and on the other hand can give us some details about query execution within a session. For example, for the code above you can write a test like this:

// Requires hibernate.generate_statistics=true
@SpringBootTest
class OwnerServiceTest {

    @Autowired
    private OwnerService ownerService;

    @Autowired
    private EntityManagerFactory entityManagerFactory;

    @Test
    @Transactional
    void registerOwner_issuesExactlyOneInsert() {
        // given
        Statistics statistics = entityManagerFactory
                .unwrap(SessionFactory.class)
                .getStatistics();
        statistics.clear();

        // when
        ownerService.registerOwner("John", "Doe");

        // then
        assertThat(statistics.getEntityInsertCount()).isEqualTo(1);
        assertThat(statistics.getEntityUpdateCount()).isZero();
        assertThat(statistics.getEntityDeleteCount()).isZero();
    }
}

This API lets you verify that only one INSERT was executed within the method. It works based on the fact that in the test I opened a transaction (Spring Boot Test of course recognizes this and opens a transaction that will have to roll back at the end),
thereby opening a Hibernate Session - this is the default behavior, so I think there are no surprises here.

Since the Statistics API collects statistics at the SessionFactory level, not at the level of individual Sessions, in each test we have to access the SessionFactory in order to first clear all its statistics.
And only then can we make the checks we're interested in (Strictly speaking, some telemetry is also collected at the Session level, but it's rather scarce and in practice can help you little).

Overall, the telemetry collected (the number of INSERT, UPDATE, DELETE statements, and so on) will be enough for you to make some basic checks.

Conclusions

In practice, the answer to the question:

"Is there a verify Hibernate behavior in tests (like Junit for example)?"

Strongly depends on what exactly you want to detect. Some tooling can be written — for example, Axelix can detect both In Memory Pagination, and N + 1, and a number of other problems. In some situations tests will help you a lot.
In general, first of all it's better to ask yourself — what problem exactly are we trying to solve here. And only then build a solution: is it possible (considering what I wrote above) to write an effective test,
is it possible to delegate this to external tooling, or maybe (the ideal case) the problem doesn't need to be solved in the first place.

Best of luck to everyone!