DEV Community: smotastic

GivenWhenThen Pattern

smotastic — Mon, 28 Sep 2020 19:10:04 +0000

There are lots of different ways on how to write, organize and structure your tests.
One of these patterns is Given-When-Then.

The term was developed as part of the Behavior-Driven Development process (https://dannorth.net/introducing-bdd/).
In general it describes a pattern on how to write, and describe a desired scenario.

Given describes the initial scenario
When describes the event that happens, which will change the scenario
Then describes the expected outcome of the scenario after the event happened

Example Scenario

Defining a scenario using this pattern could look like this.

Scenario: A user wants to buy a book from a well known e-commerce platform.

Given the user owns no books from this platform.
When the user orders and receives the ordered book from the platform.
Then the user should have one book in his possession.

Test-Scenarios in Java

When using this pattern in the world of Software-Development-Testing, it is important to agree on conventions made by the team. This ensures the consistency of all written tests.

Consistency is a big advantage in helping to quickly understand, and also learn how certain usecases are supposed to work.
Imagine a new developer joins the team. Merely by reading the tests he will gain knowledge of how something should, and even might work in the application.

In general, these conventions should be defined and agreed upon by the team. In the case of the Given-When-Then pattern I always pay attention to two factors.

Structuring the testmethod
Naming the testmethod

Structure of the Testmethod

As the pattern says, there are always three parts in any given scenario (or usecase),
and the testmethod can be structured in exactly these three parts.

First is always the given part. The initial values for the scenario. This is basically the setup for any test.

Second the when part. This is the execution of the desired method that is to be tested, or as specified before, the event that happens.

Third the then part. The verification, or assertions of the values after the event happened.

Putting this structure into a test, which tests the functionality to buy a book, could look something like this.

// given
String shouldBuyer = "hanswurst@test.com";
Long anyBookId = 1L;

// when
UserBook actual = sut.buyBook(shouldBuyer, anyBookId);

// then
assertThat("the actual owner of the book, should be the buyer", 
    actual.getBuyer(), equalTo(shouldBuyer));

Name of the Testmethod

Normally I prefer short self-documenting names for methods.
For tests though, I cut the "short" from this preference.

A test should always say what it is trying to test. Of course, you could do this by documenting it with some Javadoc, or you could just name the test the way you would normally document it.

Applying the Given-When-Then pattern to this definition, the name for our book-buying test could look something like this.

@Test
public void givenValidUserNameAndBookId_whenBuyBook_thenUserShouldOwnNewBook() {
    ...
}

If you ever googled the topic of long method names, you probably know that there are a lot of discussions on this topic, and they are for a good reason.

Long names can imply a complex implementation for a method.
And if you don't think you can shorten the name of the method, without losing information that the developer might require to understand the method, it's probably true that it's too complex.

For tests on the other hand, this argument doesn't apply. We are just testing an implementation, and not implementing some logic. The tests are also not called from anywhere else but the test runner, so we are not cluttering our code with long method calls.

Conclusion

The Given-When-Then pattern can be used to define any given test scenario.
Implementing it in the world of Software-Development can be done by following conventions agreed upon by the team.
That is true for other patterns too.

So I would like to conclude by saying whatever Pattern, Libraries or whatever Framework your team chooses to use,
the most important thing is that your team agrees on what they use, so you can ensure a consistent way of developing and testing your software.
This will help the team in the long run to further develop features, maintain the application and keep understanding what in the world is happening here.

Layer vs Feature Architecture

smotastic — Thu, 27 Aug 2020 17:50:01 +0000

I recently joined a new Project, and as always one of my first tasks was to become familiar with the existing codebase.

In this JEE-Project, one of the most important things for me was to learn how the classes were distributed into different packages. Having this knowledge would mean that, even if I didn't know how something worked, I could easily know where to look and then learn how the code works.

In this blog post, I want to show two of the most commonly known architectural design patterns on how one could organize the code.

Layer Architecture

Or the horizontal approach.

Imagine a cake with multiple layers.

Each layer represents a package.

Each package contains exactly what this layer is responsible to do.

So imagine you organize your code into 4 Layers, let's say:

UI
Businesslogic
DAO
Model

(this of course is not the most optimal way of organizing your layers and is only used for easy representation purposes)

We would have 4 layers, or 4 packages.

The UI is responsible for handling everything UI related. So this is where every UI class related to any feature would be created.

The same applies to the other three layers. Businesslogic is responsible for everything related to business-rules, DAO handles the Database-Access, Model contains for example the Object Relational Model for the underlying database.

If we would want to build an application that can create some tasks, and then list them, we could divide them accordingly into the 4 packages.

UI
- TaskListController.java
- TaskCreateController.java
Businesslogic
- TaskListBusinessrule.java
- TaskCreateBusinessrule.java
DAO
- TaskListDao.java
- TaskCreateDao.java
Model
- TaskListModel.java
- TaskCreateModel.java

Advantages

Adding new classes in such an environment is really easy.
For example, if someone would want to create a new Model-Class, he could simply do it by adding it to the Model package without thinking twice.

This also means that new team members will have an easy time learning on how to organize the code.

Disadvantages

A big disadvantage for this approach is, that it is really hard to assess the complexity of a feature, because you don't know where a feature is or might be used, and what dependencies it might have to other features.

Also, think about encapsulation. Everything must be public.

The Businessrule probably has to access the DAO in some way.
But why can the UI also access the DAO? Because either only other DAO's can access my DAO, or everyone can.

Of course, this Argument only applies if you are still using Java8 like myself.
Else you could use Jigsaw (Java9 Module-System) to create modules.

Feature Architecture

Or the vertical approach.

Imagine a cake, with multiple slices.

Each slice represents a package.

Each package contains exactly what this feature is responsible to do.

So imagine our App-Example from before, if you would organize your code into a feature-like package structure, it could look like this.

TaskList
- TaskListController.java
- TaskListDao.java
- TaskListBusinessrule.java
- TaskListModel.java
TaskCreate
- TaskCreateController.java
- TaskCreateDao.java
- TaskCreateBusinessrule.java
- TaskCreateModel.java

Advantages

In contrast to the Layer Architecture, you can actually use encapsulation in such a structure, as every Feature is encapsulated in his own package. Only the API's that really have to be public, can be public.

In modern architectures, it's very common to create micro services. With this structure already in place, it's really easy to extract existing features, into a micro service architecture.

Extandibility (if this is a word, it suits here):
If a feature needs to be extended by some functionality, you immediately know where you have to go, and in what context you will work.
You can also be more certain, that with changes to some features, you will probably not break the whole application by doing so, only the feature that you are working on.

Disadvantages

Big Applications with lots of features, will quickly grow in not only their amount of classes, but also their amount of packages. On the one hand, it might be hard to keep track of all the features, but on the other hand it might also be easier to identify certain features, if the packages have more meaningful names than just their layer.

You actually have to know what you are doing. If this is a disadvantage or not, you should decide for yourself. But also think about new people joining the team. Instead of immediately having the right place for each class, they actually have to know what they are currently working on, to precisely choose the correct package for their new class.

Conclusion

So what should you choose for your Project?
As always it depends.

In general, and based on the amount of advantages I've listed for one of the patterns, I prefer the Feature Architecture. It gives you more stability in the way you are working. If you change a class, you don't actually have to do a regression test on the whole application (at least in theory).
But the Layer Architecture also has it's strengths. I imagine that in smaller projects, this kind of architecture would actually be beneficial, because you can get a faster overview of all your classes.

I would like to conclude by saying that neither of these solutions is the correct answer to all your problems. Each team should find out what kind of architecture fits for their requirements, or for their project.
In a lot of cases I've seen a combination of the two.
You could organize your classes into Feature-Packages (Feature Architecture), and in these packages you divide your classes into the layers (Layer Architecture).
Only the team can decide, what is good for it.

DEV Community: smotastic

GivenWhenThen Pattern

Example Scenario

Test-Scenarios in Java

Structure of the Testmethod

Name of the Testmethod

Conclusion

Read more

Layer vs Feature Architecture

Layer Architecture

Advantages

Disadvantages

Feature Architecture

Advantages

Disadvantages

Conclusion