Presenting with IntelliJ IDEA

In this screencast we’re going to look at some ways to level up your presentation skills with IntelliJ IDEA.


00:00 – Intro
00:11 – Presentation Assistant plugin
00:57 – Presentation Mode
02:06 – Mouse Zoom
02:43 – Font
03:11 – Theme
03:48 – Tool windows
05:13 – Find Action & Soft-wrap
05:58 – Shortcuts & Navigation


• IDE viewing modes:
• IntelliJ IDEA keyboard shortcuts:
• IntelliJ IDEA reference card:
• Configure keyboard shortcuts:
• Creating custom shortcuts:
• Source code navigation:
• Example code:

Using Git Interactive Rebase

This article was published on on August 25, 2022.

This tutorial will cover how to clean up your Git commit history with Git interactive rebase, both via the IntelliJ IDEA UI and from the command line.

Git interactive rebase allows you to change individual commits, squash commits together, drop commits or change the order of the commits.

This allows you to clean up your Git commit history to make it linear and meaningful, which can make it easier to understand the history of the project in the future.

Open the Git window in IntelliJ IDEA using ⌘+9 on Mac (or Alt+9 on Windows & Linux). In the Git log window we can see the commits that were made to the project.

We will use a Git demo project available on GitHub. This example uses TDD (Test Driven Development) to add a new feature.

In TDD, we start by adding a failing test, writing the minimum of code we need to get that test to pass and finally do some refactoring.

Even though we made the necessary changes in multiple commits, we don’t need to keep all these individual commits for future reference.

Using Git interactive rebase in the UI

We can use Git Interactive Rebase in IntelliJ IDEA as follows:

In the Git history, identify the commit from where you want to clean up your history. That will be the oldest commit in the series of commits you want to clean up; in this example, the first failing test that we added.

Right-click on the commit from where you want to clean up your history and select “Interactively Rebase from Here…“.

IntelliJ IDEA context menu with the option "Interactively Rebase from Here..." highlighted in blue

This will open the “Rebasing Commits” popup window with a list of the commits that were done on top of the selected commit.

IntelliJ IDEA "Rebase Commits" dialog

Notice there are several options at the top of this popup, that become active when we select one or more of the commits:

  • Reword allows us to change the commit message of a specific commit.
  • The Squash button is actually a dropdown that allows us to choose between Squash and Fixup. Both options will combine the changes made in the selected commits into one commit. If we select squash, by default the individual commit messages will be combined. If we select fixup, the commit message of the fixup commit will be discarded. You can select fixup while in the “Rebasing Commits” popup with ⌥+F on Mac (or Alt+F on Windows & Linux)
  • Drop allows us to drop one or more commits.

Changing the order of the commits

Let’s say we want to change the order of the commits; we want to keep the unrelated change, but separately from the changes for the new feature. We can select this commit and use the up and down buttons on the top left to change where in the order this commit will be.

List of commits in the "Rebase Commits" dialog window, with one commit selected.
List of commits in the "Rebase Commits" dialog window, with the  selected commit moved down.

Once we’re sure about the order, select “Start Rebasing“. We see in the Git log that the order of the commits has changed.

Combining multiple commits into one commit

Next, we want to combine multiple commits where we added the tests and implemented the new feature. Let’s reopen the “Rebasing Commits” window and select those commits.

List of commits in the "Rebase Commits" dialog window, with several commits in a row selected.

Now, because we want to combine those commits into one commit with one commit message we select “Fixup“, and then select “Start Rebasing“.

The Squash dropdown selected, with the Fixup option selected in the "Rebase Commits" dialog window.
List of selected commits in the "Rebase Commits" dialog window, shown in a tree structure ready for Fixup.

In the Git log, we can see that multiple individual commits are now combined into one commit with one commit message.

Drop a commit

Finally, we want to drop the commit with a mistake that we made. Let’s reopen the “Rebasing Commits” window, select the mistaken commit, select “Drop” and select “Start Rebasing“.

List of commits in the "Rebase Commits" dialog window, with one commits selected.
List of commits in the "Rebase Commits" dialog window, where the selected commit it shown with strike through.

We see in the Git log that the commit is dropped.

Rename a commit

Now that we have cleaned up our commit history, we might want to rename the commit where we added the new feature. We have several options to do so.

We can do so using Git interactive rebase, in the “Rebasing Commits” popup, by selecting the commit you want to rename and clicking the “Reword” button at the top of the popup. This will open a small editor pane where you can reword the commit message for this commit, apply the change to the message and select “Start Rebasing“.

Open dialog to Reword the commit message.

You can also edit the commit message directly in the Git log window. Right-click the commit you want to rename and select “Edit Commit Message” or press F2 on macOS, Windows or Linux.

IntelliJ IDEA context menu with option "Edit Commit Message" highlighted.

This will open a “Edit Commit Message” popup, where you can edit the commit message and click “Ok” (or “Cancel“) when you are done.

IntelliJ IDEA "Edit Commit Message" dialog.

See which Git commands were executed

To see which Git commands IntelliJ IDEA performed, open the “Console” tab in the Git window.

Using Git interactive rebase from the command line

Let’s take a look at how to use Git interactive rebase from the command line.

In the Git history, identify the commit just before the commit from where you want to clean up your history. In this example, that will be the last commit before we started adding the new feature.

Find the commit hash for this commit in the “Commit Details” to the right of the Git history in the Git window and copy this commit hash. (Spoiler: the commit hash in this example is 34bb0f99.)

IntelliJ IDEA Git history, showing the details of a selected commit, with the commit hash `34bb0f99` highlighted.

Open the Terminal window, using ⌥F12 on Mac (or Alt+F12 on Windows & Linux) and type git rebase -i 34bb0f99 (where 34bb0f99 is the commit hash we copied above).

Terminal with the command `git rebase -i 34bb0f99`

This will open an editor in the terminal with the list of commits that were done on top of the selected commit. Each line in this file is an individual commit.

Terminal with vi editor open, showing a list of commits.

By default, Git will use whatever you have set as your default text editor. If you haven’t set one, it will fall back to the vi editor, which is what we will use in this tutorial.

Changing the order of the commits

Let’s say we want to change the order of the commits; we want to keep the unrelated change, but separately from the changes for the new feature. We can do so by changing the order of the lines (individual commits) to reflect the order we want.

In the editor in the terminal, switch to edit mode by pressing I to be able to edit this file.

We can change the order of the lines by removing the commit we want to move from the list and inserting it in the place where we want it.

In vi, we can do so as follows:

  • Place the cursor anywhere on the line you want to move (in this example the commit “Unrelated changes”) and remove this line by typing dd.
  • Move the cursor to the line where you want to reinsert this commit (in this example, the end of the file) and type p.
  • Note: you do not need to switch to edit mode to do so.
Terminal with vi editor open, showing a list of commits. The bottom commit is highlighted.

Once we’re sure about the order, we need to save the file. Press esc to exit edit mode and type :wq to save the file.
Note: If you made changes to the file that you do not want to save, type :q! to force quit.

The interactive rebase will be applied. We see in the Git log that the order of the commits has changed.

Combining multiple commits into one commit

Next, we want to combine multiple commits where we added the tests and implemented the new feature. In the terminal, type git rebase -i 34bb0f99 to start rebasing. If you have already run this command, you can press the up arrow  in the terminal to show the last used command(s).

This will again open an editor in the terminal with the list of commits.

Switch to edit mode in the editor in the terminal. In vi, you can do so by pressing I.

For each of the commits we want to combine, replace “pick” with “fixup”.

Note that we use “fixup” because we want to use one commit message for the combination of the commits. Alternatively, we could use “squash” to combine the individual commit messages into the new commit message.

Terminal with vi editor open, showing a list of commits. For several commits `pick` is replaced with `fixup`.

Once we have correctly edited all the commits we want to combine, save the file.
In vi, press esc to exit edit mode and type :wq to save the file.
The interactive rebase will be applied. In the Git log, we can see that multiple individual commits are now combined into one commit with one commit message.

Drop a commit

Finally, we want to drop the commit with a mistake that we made. In the terminal, type git rebase -i 34bb0f99 to start rebasing.

To drop a commit, remove that commit from the list of commits. In this example, we will remove the commit “Mistake”.

In vi, we can remove a line by placing the cursor anywhere on the line we want to remove and typing dd. Alternatively, we can switch to edit mode by pressing I and removing the line manually. Press escto exit edit mode.

Terminal with vi editor open, showing a list of commits.

Save the file by typing :wq and the interactive rebase will be applied. We see in the Git log that the commit is dropped.


Now we know how to use git interactive rebase either from the IntelliJ IDEA UI or from the command line. Give them a try and use whichever way you prefer.

IntelliJ IDEA Shortcuts Used

Here are the IntelliJ IDEA shortcuts that we used.

NamemacOS ShortcutWindows / Linux Shortcut
Open the Git Tool Window⌘9Alt+9
Open the Commit Window⌘0Alt+0
Open the Terminal⌥F12Alt+F12
Select Fixup (in the “Rebasing Commits” popup)⌥F12Alt+F
Edit commit message (in the Git Log)F2F2
IntelliJ IDEA shortcuts

Git commands Used

Here are the Git commands that we used.

Nameterminal command
Git interactively rebase from a specific commit with commit hash, for example 11aa23bcgit rebase -i 11aa23bc
Use this commitpick
Fixup this commit (add changes to previous commit under the same commit message)fixup
Squash this commit (add changes to previous commit and combine commit messages)squash
Git commands

vi Shortcuts Used

Here are the shortcuts that we used.

Open interactive (edit) modeI
Exit interactive (edit) modeesc
Remove line (note: not in edit mode)dd
Reinsert line (note: not in edit mode)p
Write and quit:wq
Force quit:q!
vi shortcuts

Related Links

Using Git interactive rebase in IntelliJ IDEA

Git interactive rebase allows you to change individual commits, squash commits together, drop commits or change the order of the commits. This allows you to clean up your git commit history to make it linear and meaningful, which can make it easier to understand the history of the project in the future. Let’s take a look at how this works.

For more information, see Using Git Interactive Rebase.

Use Testing to Develop Better Software Faster

This blog post was first published on the 97 Things blog on Medium and is published in the book “97 Things Every Java Programmer Should Know” (O’Reilly Media).

Book cover of “97 Things Every Java Programmer Should Know", which includes "Use Testing to Develop Better Software Faster".
Book cover of “97 Things Every Java Programmer Should Know”

Testing your code will help you verify your code does what you expect it to do. Tests will also help you to add, change, or remove functionality, without breaking anything. But testing can have additional benefits.

Merely thinking about what to test will help to identify different ways the software will be used, discover things that are not clear yet, and better understand what the code should (and shouldn’t) do. Thinking about how to test these things before even starting your implementation could also improve your application’s testability and architecture. All of this will help you build a better solution before tests and code are written.

Alongside the architecture of your system, think not only about what to test but also where to test. Business logic should be tested as close as possible to where it lives: unit tests to test small units (methods and classes); integration tests to test the integration between different components; contract tests to prevent breaking your API; etc.

Consider how to interact with your application in the context of a test and use tools designed for that particular layer, from unit test (e.g., JUnit, TestNG), to API (e.g., Postman, RestAssured, RestTemplate), to UI (e.g., Selenium, Cypress).

Keep the goal of a particular test type in mind and use the tools for that purpose, such as Gatling or JMeter for performance tests, Spring Cloud Contract Testing or Pact for contract testing, and PiTest for mutation testing.

But it is not enough to just use those tools: They should be used as intended. You could take a hammer to a screw, but both the wood and the screw will be worse off.

Test automation is a part of your system and will need to be maintained alongside production code. Make sure those tests add value and consider the cost of running and maintaining them.

Tests should be reliable and increase confidence. If a test is flaky, either fix it or delete it. Don’t ignore it — you’ll waste time later wondering why that test is being ignored. Delete tests (and code) that are no longer valuable.

A failing test should tell you exactly what is wrong quickly, without you having to spend a lot of time analyzing the failure. This means:

  • Each test should test one thing.
  • Use meaningful, descriptive names. Don’t just describe what the test does either (we can read the code), tell us why it does this. This can help decide whether a test should be updated in line with changed functionality or whether an actual failure that should be fixed has been found.
  • Matcher libraries, such as HamCrest, can help provide detailed information about the difference between expected and actual result.
  • Never trust a test you haven’t seen fail.

Not everything can (or should) be automated. No tool can tell you what it’s actually like to use your application. Don’t be afraid to fire up your application and explore; humans are way better at noticing things that are slightly “off” than machines. And besides, not everything will be worth the effort of automating.

Testing should give you the right feedback at the right time, to provide enough confidence to take the next step in your software development life cycle, from committing to merging to deploying and unlocking features. Doing this well will help you deliver better software faster.

Cukenfest 2018 — It’s all about the conversations

This article was first published on Medium.

In April of 2018, I attended Cukenfest; a BDD and Agile conference organised by the people at Cucumber. As a Cucumber user and open source contributor, this was a great way to meet some people I’d previously only chatted with on Slack, as well as hear some great talks by amazing people.

Preconference Dinner

The evening before the conference, we got together at a local pub with both conference speakers and Cucumber contributors. Here I finally got to meet people I’d been collaborating with in person! It was great getting to know them better, and discussing our experiences with Cucumber and BDD.

We also bonded over other topics, like a shared love of Kotlin , or dealing with a similar challenge of moving more towards a Software Engineering role from a tester role.

The highlight of the evening, other than meeting so many great people, might have been the discussion we had about Cucumber expressions, which were already available in the Ruby and JavaScript implementations, and have since been added to Cucumber-JVM.

Lots of smart people, with lots of interesting ideas and experiences to share.

Day one

The first day of the conference had a great lineup of talks by amazing speakers, including Dan NorthLiz KeoghGáspár NagyNat Price and Aslak Hellesøy (the creator of Cucumber). Speakers were introduced by Seb Rose, who could very well have a career as a standup comedian (you know, if this IT thing doesn’t work out).

If you’d like to read more about their talks, I highly recommend the blog by Katja: which also includes her sketch notes. Or watch the videos.

Speed meet

After the first round of talks, there was an opportunity for a speed meet; inspired by the European Testing Conference. The format of the speed meet was to have people draw a mind map about themselves as input to 3 minute conversations they would have with other attendants. Rows of chairs are set up facing each other and after every three minutes, people shift places so they end up talking to someone else. This is a great way to get conference attendees to talk to each other. Some people might find it a bit intimidating, but it does seem to foster more communication. The only downside for me is that it can get very loud!

Hallway track

At some point, I ran into Victoria Wiggins in the hallway. She had just done an amazing talk on neurodiversity and this provided the chance to tell her how how inspiring it was. It really showed a great self acceptance! While this led me to miss some of the scheduled talks, we had the opportunity to discuss (neuro)diversity in the workplace.

Personally, I really appreciate the hallway track at conferences, as it gives you the opportunity to meet people, and get different perspectives on things. This really reinforces the learning, as well as foster a community.

Day two

The second day of the conference was an open space, or `unconference`. This day was particularly geared towards interaction between participants.

Matt Wynne introduced us to the rules of the game:

  1. The law of 2 feet; if you’re not learning from or contributing to a session, you can walk off in search of a different session.

2. The other rules are:

  • Whoever comes is the right people
  • Whatever happens is the only thing that could’ve
  • When it starts is the right time
  • When it’s over, it’s over

This helps make sure everyone in a sessions remains interested and engaged.


Some of us had our own sessions planned; we’d been working on improving the Cucumber documentation and wanted to see what was needed to get them live. It ended up being Matt Wynne, Sam Wright (a.k.a. Plaindocs) and myself working on the last bits and pieces and getting them live!

Later that day we had a demo session, and gathered some great feedback from participants. We’ll be slowly improving them, based on actual user feedback. But for now, we’re very happy to have them live after working on them for many months!

After conference

At the end of the day, we got to enjoy the lovely weather at the rooftop bar. We continued discussions about Cucumber, BDD, Software Engineering, working in tech, being women in tech, and so much more.

Later, a few of us went out to dinner and conversations continued, sharing ideas and experiences and getting to know wonderful people. It’s all about the conversations…

Open Source Day

The next day, we had an Open Source Day, where we got together to discuss upcoming changes to various implementations of Cucumber, as well as how to continue improving the documentation. I got to meet some more Cucumber contributors, which was loads of fun. We even managed to get a few things done!

Collaborating on open source

This article was first published on Medium.

Using open source projects has become increasingly popular. The number of companies using open source is growing. Unfortunately, the number of people building and maintaining it is not growing quite as fast.

Open source doesn’t come for free; someone is doing the work. And they could use your help!

Why you should contribute to open source

There are many reasons why you might want to contribute to open source.
Personally, I started because I was looking for a way to learn more about programming, and wanted to do so in a way where I might contribute something useful.

Then, I continued doing it because I enjoyed the collaboration and feeling useful and appreciated. Also, I did learn new things I was able to use at work. Your reasons might be entirely different!

I’ve heard people also contribute to open source to give back to the project or community, to build their CV, to “scratch an itch” (fix a problem they are having), or a variety of other reasons.

Ways to contribute

The most obvious thing you can do is to fix bugs, or add new features. If this is something you can do, please do! Unfortunately, this can take considerable time and coding skill, which not everyone might have. So how can you contribute, if you are not a programmer with lots of spare time?

There are many things that you can do that don’t involve coding and don’t (have to) take a lot of time. I have listed some below, along with some examples of my own contributions.

Writing documentation

One of the ways to contribute is by adding to the documentation. This is often mentioned as an easy way to get started. You don’t need to know how to code to do it; you don’t even necessarily need to know a lot about the whole project (depending on the change).
If you are adding content, you do need to be able to write well, and articulate ideas clearly. Other skills that might help are attention to detail (like spelling and grammar), coming up with good examples, etc.
Even if writing is not your strength, there are still many ways in which you can help:
* Read documentation to see if it is clear and complete. If not, offer suggestions on how to improve it. Or at least inform maintainers what is unclear to you and why.
* Fix small things, like typos or dead links, if you can. For example, some small contributions I’ve made were fixing a dead link in the Docker documentation and fixing a typo in a Pitest error message.
* Let maintainers know if you find typos, dead links, mistakes, outdated or missing information. It’s really hard to keep a fresh eye on documentation you might have rewritten and edited multiple times!
* Add information that is missing, especially if it is something you had to find out for yourself (either with or without the help of the community). Someone else might have the same problem.
* Add (links to) relevant blog posts. If the blog post is your own, consider adding relevant information from your blog post to the official documentation also. You can still offer a different perspective in your own blog.
* Review any open PR’s (pull requests) on the documentation. Look for the things mentioned above: it is clear, complete, correct? Do you see any typos or other mistakes? (Have I mentioned it’s hard to spot typos in something you’ve been working on for a while?)
I, for one, love getting reviews on my documentation PR’s; the suggestions make them so much better! And I love how this makes each PR the product of collaboration, rather than one person.

And for all of these: if it is something you can do yourself, please do so!

Answering questions

As a user, you can probably help other users with problems you have faced before. Remember, someone probably helped you in the past in one way or another. Share what you have learned!
And if you notice a lot of similar questions, consider adding to the documentation. We have recently added a FAQ page to the Cucumber documentation, and would love additional contributions to the page. Other projects probably will too!

Creating an issue

The least you can do if you encounter a problem, is create an issue. Maintainers might not all use the project in the same way, and might not be aware there is an issue unless you tell them.

Before creating an issue, please check that there isn’t an open issue for the same problem (prevent duplication). If there is, you might be able to add additional useful information to that issue.

If you are not sure you have found a bug, please contact the community to ask them. Most projects will have one or more ways for you to ask questions (Gitter, Slack, mailing groups, etc). It will often be quicker to get help that way, as more people in the community can help you (not just the maintainers who monitor GitHub issues). This might also start up a dialog on what the exact issue is, how to reproduce it etc. which will make it easier to fix.

When you do create an issue, please be as specific as you can and provide sufficient information to help maintainers understand and reproduce your issue. Many projects use templates requesting the type of information they need; make use of them! Or, if they don’t use a template yet, maybe you can add one to the project?

And again, if it is something you can fix yourself, please do!

Reproducing issues

When someone opens an issue, a maintainer needs to look at it to understand the problem. This is where you can help! Is the issue clearly described, and does it contain sufficient information to reproduce the issue? If you can reproduce it, you might be able to provide additional helpful information.
And if you can’t, you could ask the original author for more information. Or maybe the issue can be closed!

Add unit tests

If you know how, you could try to add a unit test that reproduces the issue, which both shows there is an issue and will help getting it fixed. And if you can, fix it yourself. My first contributions to Cucumber-JVM were unit tests; the first one to show that a particular (old) issue had already been resolved, and another to reproduce an issue. Fortunately, I was also able to fix it too!

Labelling issues

Many projects on GitHub use labels, to signify the type of issues. Which labels are used will vary per project, but using labels can help people either find an issue similar to theirs (preventing duplicate issues from being created), or help people find issues they could contribute to.
Adding the right labels to issues can help both maintainers and users of the project, and is something other maintainers might not have time for.
Note: as far as I know, you do have to have access to the project to be able to add labels, so this is not something you can do when you first get started.

Review PR’s

Reviewing incoming PR’s can be a lot of work. If you are not too familiar with the code base, you might not be able to say anything about the overall usefulness or direction of the PR, but you might still be able to help. For starters, you could check the readability of the code, see whether the test coverage is good, look for typos, etc. Alternatively, you might be able to build the branch locally and test it yourself to see if it solves whatever issue it was designed to solve. Even if you can’t read code, you can probably still review documentation PR’s (see above). Reviewing PR’s can also be a great way to gain experience with reading code, and to get to know the project better.

Testing new features or versions

Maintainers and contributors don’t always have time to extensively test new features or versions. This is where you can help! Create a new project to test the new feature, or upgrade your existing project to the new version (even if it is still in development). Provide feedback to the people who are working on it.

Note: there might not be open issues registered for test work. That doesn’t mean it’s not needed! You might hear about test work that is needed, when you become a more active member of the community. If this is something you’d like to do, but you are not aware of anything that needs testing, ask the community! Even if they don’t have anything right now, they might ask you in the future.
For example, when Cucumber expressions were being implemented in Cucumber-JVM, I tried them out with a small sample project and reported my findings to core maintainers, as well as made some notes on things that should be added to the documentation.

Cleaning up code

Projects might also benefit from refactoring or cleaning up code. There will be plenty of ways the code could be improved, especially if they have been developed over several years by different developers.
One of the PR’s I did on Cucumber-JVM recently, was to make use of a parent pom.xml. This removed a lot of duplicate dependencies from the project. While doing this, I also learned more about Maven, which I have since been able to use at work.

Upgrading dependencies

If you notice a project is using outdated dependencies, see if you can upgrade them. Especially, if the older versions contain security vulnerabilities. Note that some projects might introduce breaking changes, so always make sure that the project still works with the upgraded dependency. For example, I have updated Jackson dependencies on GraphQL, due to some security issues found in older versions of Jackson.


There might be other ways for you to contribute. Even if you’re not a programmer, you might have other skills that are valuable to a project.
If you do have ways to contribute that are not mentioned here, please let me know in the comments!

How to find a project to contribute to

There are several ways to find a project to contribute to.


If you have no idea where to start, there are several websites that list projects looking for help:
* GitHub itself offers some suggestions on choosing projects.
* Have a look on CodeTriage for projects with open issues
* Look for issues by project, label (like “good first issue”) and/or tag (for example, your preferred programming language) on Up-for-grabs
* You can also find these links and more on First Timers Only

Projects you use yourself

A great tip on where to get started, is to help out with a project you use yourself. You’ll be more familiar with this project, and you might even be able to solve your own problems. If you are already be part of their community, you’ll have a better idea of what is needed.

Focus on welcoming communities!

Focus on projects that welcome new contributors. Some of the following might help:
* See if there are any issues marked “first timers only”, “good first issue” or something similar; this would signify they are open / looking for new contributors and give you an idea of where to start.
* See how they respond to issues created or PR’s opened (do they ask for more information in a polite or a hostile way, how constructive is feedback on PR’s or issues)
* Check to see if there is a code of conduct, contributing guidelines or things like that (and whether they are enforced)
* Join the communication channel(s) to see how the community interacts

Know that there are plenty of projects and communities out there who would love, love, LOVE your help! And I hope you find one, if you are looking.

Personally, I was very lucky to find the Cucumber community, who were very welcoming and helpful. When I first started, I accidentally merged something that shouldn’t have been merged yet. Unfortunately, I didn’t know a lot about Git yet, but several core maintainers helped to fix the problem (and were still nice to me). I spent the weekend doing Git tutorials, so this would never happen again! Learning more about Git has been very helpful at work; I’m even able to help out coworkers at times.

Reasons not to contribute to open source

While there are many reasons to contribute to open source, there might also be reasons not to do so.

Employer or contract doesn’t allow it

This might be a valid reason for you not to contribute, especially to the code. You might still be able to help the community by answering questions from other users, sharing your experience, creating issues or adding relevant information to them.
If your employer uses open source projects, they will also have an interest in keeping the project maintained. Instead of letting their employees contribute code, perhaps they could become a sponsor? Cucumber, and several other projects, accept donations through OpenCollective; others use Patreon, or other options. Recently, one of my coworkers donated his education budget for the year to an open source project he uses at work. I think that is a great idea!

Being a noob…

Please don’t underestimate the value of a fresh pair of eyes! Documentation, especially beginner tutorials, should be easy to follow along even for people who are new to the project. The project itself should be easy to use. If they are not, this is your chance to provide valuable feedback!
If you are having any problems when using the project, contact the community and let them know. And if they take the time to help you out, why not document what you have learned for the next person who comes along?
Even if you are not having any problems right now, you can still read the documentation and provide feedback (see above).

Not sure this is a bug, or how to fix it

If you have a question, please find out how to contact the community. Many projects have an active user community willing to help you. If you’re not sure you’ve found a bug, just ask them. They’ll let you know whether you should log an issue. They will also ask you for the information they need to fix it.
If you want to add a feature but don’t know how, there might be people to help you get started. They could point you in the right direction of where to make the change, or provide insights on where the project is going.
Proposing your change before doing a lot of work on it, will also prevent you from building a feature that might not be in line with the direction the project is taking.

Don’t have time

Again, fair enough. You might have other priorities in your life.
Not all contributions have to be big or take a lot of time. There might be small things you can do. You might be able to do them at work, if they are related to your work (and your employer allows you to!). Even engaging with the community, by asking and answering questions, or logging issues, can be very helpful!

Come collaborate with us!

Open source software isn’t free — someone else paid for it.

However you are using open source, and however little you feel you have to contribute, there are plenty of small ways you can make open source better.
I hope I’ve given you some ideas to try. Please go and find a way you can contribute to your favourite open source project!

Overview of cucumber community
Cucumber community

How to pass the Java SE 8 Programmer I exam

This article was first published on Medium.

This post describes how I passed the Java SE 8 Programmer I exam.

Why take the exam

Opinions differ on how useful it is to pass this exam. It certainly isn’t easy. You’ll need to know quite a lot about Java syntax, and what the compiler will or will not allow you to do. However, it does not teach you to be a good Java programmer; you don’t have to write any actual code, and the code examples provided are definitely not clean code. They might even be anti-patterns.

Exam guide

When I took the exam, there was only one study guide available for Java 8:

OCA: Oracle Certified Associate Java SE 8 Programmer I Study Guide: Exam 1Z0-808 by Jeanne BoyarskyScott Selikoff

Overall, this guide was very helpful. It covers what you need to know, and provides practice questions at the end of each chapter, as well as several practice exams (which are also accessible online). It also provides great tips on how to pass the exam. The best tip for me was: for each question, if one of the options is “does not compile”, check if the code example will compile before looking at any of the other answers.

Personally, I found the book very helpful. Although some topics weren’t quite clear enough for me, and I did end up googling additional information.

In the mean time, other guides have become available. Since I didn’t use them, I can’t comment on their quality. I might try the guide by Mala Gupta, as I found her Java 7 version to be quite concise (which is helpful if you need to know exactly what will or won’t compile).


Another thing I did was write lots of code snippets to figure out some details; this way you see exactly what will compile or not, and what the result will be. It will help you find some common mistakes everyone makes when first starting out (missing semi-colons and brackets, etc.). And running code with a debugger will help you understand better what’s going on.

Mock exams

Apart from studying the exam topics, both by reading and trying out code, I found practice exams essential. Practice taking the exam as much as you can! Any exam guide will likely offer one or more practice exams. In addition, you can buy more mock exams.

In my case, I bought exams from Enthuware, which are good quality and not very expensive. They helped me learn the how to answer the types of questions you might expect on the exam, as well as to manage my time. (Pro tip: mark questions you’re not sure of and come back to them later. Do answer them; an answer that may or may not be correct, is better than no answer which is sure to be incorrect).

In addition, it showed me which areas were my weakest. Then, I would research those topics some more and clear up any confusion I had before doing another mock exam. Once I was consistently passed the mock exams, I also passed the actual exam.


Because my employer at the time paid for it, I also did a course at Oracle. This one week course covers all of the topics, with some exercises. It is useful to have an instructor to help explain things to you. If you don’t take the course, you might have to ask friends or coworkers. In my opinion, doing more mock exams (even if you pay for them yourself) is better value for money. But if your employer is willing to pay for the course, it can’t hurt.


If you want to pass the exam, it will take some work. Don’t just read a book, but practice; both with code and with mock exams.

The exam is not easy and therefore does show that you have a firm grasp of the language. However, it doesn’t show that you are able to use it well. For that, you’ll need actual experience.

Managing state in Cucumber-JVM using Spring

This article was first published on Medium.

A frequently asked question about Cucumber-JVM is how to share state between steps. This post describes how to use Spring with Cucumber to help you share objects between steps, without accidentally sharing state between scenarios (a common cause of flaky scenarios).

First of all, why not use static variables?

A solution often seen to share variables or objects between steps, is to declare static variables at the top of the step definitions file. However, there are several downsides this approach:

  1. As your project grows, you’ll probably want to divide your step definitions into different classes, divided into meaningful groups. At that point, you can no longer use the static variables declared in one step definition file.
  2. Using static variables might cause your tests to accidentally leak state into other scenarios, making them unreliable. Test automation is only any good if it is reliable.

Using Dependency Injection

The recommended solution to share state is to use Dependency Injection (DI). Cucumber supports several DI frameworks, including PicoContainer, Spring and Guice.

Using Dependency Injection with Cucumber will bring you several benefits:

  • You can safely share state between your steps
  • It will help improve the design of your test code; making it easier to share state between different step definition classes (so you can split them into meaningful groups).
  • It will create and manage instances of classes for you.

Choosing a Dependency Injection framework

If your project already uses Dependency Injection, you could use the framework you already have. If not, consider using PicoContainer; it’s very light-weight and easy to use (at least, this is my personal experience in side projects).

Since my team already uses Spring in our projects, we’ve opted to use Spring with Cucumber.

Adding the cucumber-spring dependency

In order to use Spring with Cucumber, we need to add a cucumber-spring dependency to our pom.xml:


Other dependencies

If you are using Spring and Cucumber in your project, you will already have those dependencies. Otherwise, you should add those as well.

Annotation based configuration

If you are using annotation based configuration, you can register your classes as Beans to be managed by Spring:

  • Add the @Component annotation to each of the classes you’d like Spring to manage for you.
  • Add an annotation to specify the scope: the @Scope("cucumber-glue"), in order to have cucumber-spring remove them after each scenario!
  • Add the location of your classes to the @ComponentScan of your (test) configuration.
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

public class Config {

This approach works for any classes that you have defined yourself. This may include:

  • domain objects (like a “Customer” or an “Account”)
  • any other step definition files (if you have split your files)
  • any “services” or “helper” classes you extract to represent parts of the system your tests interact with (like PageObjects, REST API’s, etc.). The steps can then call these services/helpers, instead of each other.

If you are using classes that you have not defined yourself, you cannot annotate them as Components for Spring to find with the component scan. You will have to explicitly register them as Beans in your (test) configuration.

Here is an example, using Selenium WebDriver:

import org.openqa.selenium.WebDriver;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Scope;

public class Config {
    public WebDriver webDriver() {
        // return a driver with desired capabilities

In our latest projects, we are using SpringBoot. We can annotate our StepDefinitions class with @SpringBootTest(classes = [Config.class]);.

XML configuration

Alternatively, you can specify your beans in a .cucumber.xml file, like this. Here is an example (again using Selenium WebDriver; this could also be one of your own classes):

<bean class="org.openqa.selenium.WebDriver" scope="cucumber-glue" />

You can annotate your StepDefinitions with @ContextConfiguration("classpath:cucumber.xml").

Using the Beans

You can now use the Beans, by autowiring them where you need them.

For example, you can Autowire your WebDriver to your PageObject:

import org.openqa.selenium.WebDriver;
import org.springframework.beans.factory.annotation.Autowired;

public class PageObject {
    WebDriver driver;    // the rest of your page object


As you can see, it is relatively easy to add Cucumber-Spring to manage state. You are now able to safely share state between your steps, as well as split your step definition files into meaningful groups.

This will make your project easier to understand and maintain, and your tests more reliable.

Getting started with Cucumber in Java — A 10 minute tutorial

This article was first published on Medium.

This tutorial will tell you how to get started with Cucumber-jvm in Java. It is intended as a brief, easy guide. For more examples on how to use Cucumber with Java or Kotlin, check the links at the bottom of this tutorial.


To get started with Cucumber in Java, you will need the following:

  • Java SE — Java 8 (Java 9 is not yet supported by Cucumber)
  • Maven — Version 3.3.1 or higher
  • An IDE editor, for example IntelliJ IDEA (which will be used in this introduction; the community edition is free!)
  • A Cucumber plugin for your IDE, for example IntelliJ IDEA Cucumber for Java plugin to go with IntelliJ IDEA

Setting up the project

First, we need to set up the project so we can use Cucumber.

Create a Maven project

In this tutorial, we’re using Maven to import external dependencies. We start by creating a new Maven project, which will automatically create some of the directories and files we will need.

To create a new Maven project in IntelliJ IDEA:

  1. Click the menu option File > New > Project
  2. In the New project dialog box, select Maven on the left (if it isn’t already selected)
  3. Make sure that the Project SDK is selected (for instance, Java 1.8) and click Next
  4. Specify a GroupId and ArtifactId for your project and click Next
  5. Specify a Project name and Project location for your project (if needed) and click Finish

You should now have a project with the following structure:

├── pom.xml
└── src
├── main
│ └── java (marked as sources root)
│ └── resources (marked as resources root)
└── test
└── java (marked as test sources root)

Add Cucumber to your project

Add Cucumber to your project by adding a dependency to your pom.xml:


In addition, we need the following dependencies to run Cucumber with JUnit:

</dependency> <dependency>

If you have IntelliJ IDEA configured to auto-import dependencies, it will automatically import them for you. Otherwise, you can manually import them by opening the Maven Projects menu on the right and clicking the Reimport all Maven Projects icon on the top left of that menu. To check if your dependencies have been downloaded, you can open the External Libraries in the left Project menu in IntelliJ IDEA.

To make sure everything works together correctly, open a terminal and navigate to your project directory (the one containing the pom.xml file) and enter mvn clean test.

You should see something like the following:

[INFO] Scanning for projects...
[INFO] -------------------------------------------------------------
[INFO] Building cucumber-tutorial 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------- <progress messages....>[INFO] -------------------------------------------------------------
[INFO] -------------------------------------------------------------
[INFO] Total time: <time> s
[INFO] Finished at: <date> <time>
[INFO] Final Memory: <X>M/<Y>M
[INFO] -------------------------------------------------------------

Your project builds correctly, but nothing is tested yet as you have not specified any behaviour to test against.

Specifying Expected Behaviour

We specify the expected behaviour by defining features and scenarios.

The feature describes (part of) a feature of your application, and the scenarios describe different ways users can use this feature.

Creating the Feature Directory

Features are defined in .feature files, which are stored in the src/test/resources/ directory (or a sub-directory).

We need to create this directory, as it was not created for us. In IntelliJ IDEA:

  1. In the Test folder, create a new directory called resources.
  2. Right click the folder and select Mark directory as > Test Resources Root.
  3. You can add sub-directories as needed. Create a sub-directory with the name of your project in src/test/resources/

Our project structure is now as follows:

├── pom.xml             (containing Cucumber and JUnit dependencies)
└── src
    ├── main
    │   └── java        (marked as sources root)
    │   └── resources   (marked as resources root)
    └── test
        ├── java        (marked as test sources root)
        └── resources   (marked as test resources root)
                └── <project>

Creating a Feature

To create a feature file:

  1. Open the project in your IDE (if needed) and right-click on the src/test/resources/<project> folder.
  2. Select New > File
  3. Enter a name for your feature file, and use the .feature extension. For instance, belly.feature.

Our project structure is now as follows:

├── pom.xml             (containing Cucumber and JUnit dependencies)
└── src
├── main
│ └── java (marked as sources root)
│ └── resources (marked as resources root)
└── test
├── java (marked as test sources root)
└── resources (marked as test resources root)
└── <project>
└── belly.feature

Files in this folder with an extension of .feature are automatically recognized as feature files. Each feature file describes a single feature, or part of a feature.

Open the file and add the feature description, starting with the Feature keyword and an optional description:

Feature: Belly
Optional description of the feature

Creating a Scenario

Scenarios are added to the feature file, to define examples of the expected behaviour. These scenarios can be used to test the feature. Start a scenario with the Scenario keyword and add a brief description of the scenario. To define the scenario, you have to define all of its steps.

Defining Steps

These all have a keyword (GivenWhen, and Then) followed by a step. The step is then matched to a step definition, which map the plain text step to programming code.

The plain text steps are defined in the Gherkin language. Gherkin allows developers and business stakeholders to describe and share the expected behaviour of the application. It should not describe the implementation.

The feature file contains the Gherkin source.

  • The Given keyword precedes text defining the context; the known state of the system (or precondition).
  • The When keyword precedes text defining an action.
  • The Then keyword precedes text defining the result of the action on the context (or expected result).

The scenario will look this:

Scenario: a few cukes
Given I have 42 cukes in my belly
When I wait 1 hour
Then my belly should growl

Running the test

To run the tests from JUnit we need to add a runner to our project.

Create a new Java class in your src/test/java/<project> directory, called

package <project>;

import cucumber.api.CucumberOptions;
import cucumber.api.junit.Cucumber;
import org.junit.runner.RunWith;

@CucumberOptions(plugin = {"pretty"})
public class RunCucumberTest{

Our project structure is now as follows:

├── pom.xml             (containing Cucumber and JUnit dependencies)
└── src
├── main
│ └── java (marked as sources root)
│ └── resources (marked as resources root)
└── test
├── java (marked as test sources root)
│ └── <project>
│ └──
└── resources (marked as test resources root)
└── <project>
└── belly.feature

The JUnit runner will by default use to look for features. You can also specify the location of the feature file(s) and glue file(s) you want Cucumber to use in the @CucumberOptions.

You can now run your test by running this class. You can do so by right-clicking the class file and selecting RunCucumberTest from the context menu.

You should get something like the following result:

1 Scenarios (1 undefined)
3 Steps (3 undefined)
You can implement missing steps with the snippets below:@Given("^I have (\\d+) cukes in my belly$")
public void i_have_cukes_in_my_belly(int arg1) throws Exception {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}@When("^I wait (\\d+) hour$")
public void i_wait_hour(int arg1) throws Exception {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}@Then("^my belly should growl$")
public void my_belly_should_growl() throws Exception {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
Process finished with exit code 0

As we can see, our tests have run, but have not actually done anything — because they are not yet defined.

Define Snippets for Missing Steps

We now have one undefined scenario and three undefined steps. Luckily, Cucumber has given us examples, or snippets, that we can use to define the steps.

To add them to a Java class in IntelliJ IDEA:

  1. Create a new Java class in your src/test/java/<project> folder (for instance,
  2. Paste the generated snippets into this class

IntelliJ IDEA will not automatically recognize those symbols (like @Given@When@Then), so we’ll need to add import statements. In IntelliJ IDEA:

  • Add import statements for @Given@When@Then (underlined in red)

In IntelliJ IDEA you can do so by putting your cursor on the @Given symbol and press ALT + ENTER, then select Import class.

Our project structure is now as follows:

├── pom.xml             (containing Cucumber and JUnit dependencies)
└── src
├── main
│ └── java (marked as sources root)
│ └── resources (marked as resources root)
└── test
├── java (marked as test sources root)
│ └── <project>
│ └──
│ └──
└── resources (marked as test resources root)
└── <project>
└── belly.feature

Now, when you run the test, these step definitions should be found and used.

Note: Run configurations

If this does not work, select Run > Edit Configurations, select Cucumber java from the Defaults drop-down, and add the project name to the Glue field on the Configuration tab.

Your result will include something like the following:

cucumber.api.PendingException: TODO: implement me
at skeleton.Stepdefs.i_have_cukes_in_my_belly(
at ✽.I have 42 cukes in my belly(/Users/maritvandijk/IdeaProjects/cucumber-java-skeleton/src/test/resources/skeleton/belly.feature:4)

The reason for this is that we haven’t actually implemented this step; it throws a PendingException telling you to implement the step.

Implement the steps

We will need to implement all steps to actually do something.

  • Update your class to implement the step definition.

The step can be implemented like this:

@Given("^I have (\\d+) cukes in my belly$")
public void I_have_cukes_in_my_belly(int cukes) throws Throwable {
Belly belly = new Belly();;

To make this step compile we also need to implement a class Belly with a method eat().

  • Implement the class inside your src/main/java/<project> folder; create your <project> directory here (if needed)

Our project structure is now as follows:

├── pom.xml             (containing Cucumber and JUnit dependencies)
└── src
├── main
│ └── java (marked as sources root)
│ │ └── <project>
│ └──
│ └── resources (marked as resources root)
└── test
├── java (marked as test sources root)
│ └── <project>
│ └──
│ └──
└── resources (marked as test resources root)
└── <project>
└── belly.feature

Now you run the test and implement the code to make the step pass. Once it does, move on to the next step and repeat!


Once you have implemented this step, you can remove the statement throw new PendingException(); from the method body. The step should no longer thrown a PendingException, as it is no longer pending.


Once you have implemented all your step definitions (and the expected behaviour in your application!) and the test passes, the summary of your results should look something like this:

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.656 secResults :Tests run: 5, Failures: 0, Errors: 0, Skipped: 0[INFO] -------------------------------------------------------------
[INFO] -------------------------------------------------------------
[INFO] Total time: 5.688 s
[INFO] Finished at: 2017-05-22T15:43:29+01:00
[INFO] Final Memory: 15M/142M
[INFO] -------------------------------------------------------------


To get started with a working project, try the cucumber-java skeleton project which is available from GitHub.

For more examples of how to use Cucumber, have a look at the examples provided in the cucumber-jvm project on GitHub.

If you’d like to try Cucumber with Kotlin, have a look at my blog post.

Note: This tutorial was originally written as part of the new Cucumber documentation. You can find the cucumber documentation project on GitHub. It was adapted a little here to make a stand-alone tutorial.