DEV Community: Edgar Cirilo

Git cheat sheet

Edgar Cirilo — Mon, 02 Nov 2020 09:39:15 +0000

Git has become a basic tool in the software development lifecycle. And now, in an age where it seems the world is moving to a remote approach, mastering this skill will be of great advantage to all software professionals, since it makes you a better team player and improves the lifecycle.

There are many blogs teaching Git. These are the ones that I highly recommend:

Moreover, I want to share the most common commands that I use in my daily workflow. Note that all will be using the command line:

Get the repo

# It works with https or ssh
$ git clone 'https://github.com/git/git.git'

Change Origin

# Sometimes we need to change the repo to other owner or location, 
# in order to avoid it to be cloned again, we can just change the remote origin.
$ git remote add origin 'https://github.com/moby/moby.git'

# We can verify the new remote is set correctly
$ git remote -v
> origin  https://github.com/moby/moby.git (fetch)
> origin  https://github.com/moby/moby.git (push)

Get the latest changes

# Get the latest changes in the remote repository with 'git pull'
# Remember that specifying the remote 'origin' and the branch name is always a good practice
$ git pull origin <branch-name>

# Use 'git fetch' to sync your local repository with the remote repository
# This only includes the metadata, new branches, tags, and tree history
$ git fetch

Create a new branch

# Move and create at the same time to a new branch
# Tip: Use git-flow branch naming convention: feature/*, hotfix/* and so on.
$ git checkout -b <branch-name>

Add your changes

# Add changes to Stage
$ git add <file-name>

# Add ALL changes to Stage
$ git add .

# Commit changes to the local repository
$ git commit -m "Commit message"

# Add all and commit at the same time (Only to tracked files)
$ git commit -am "Commit message"

# Push commits to the remote repository
$ git push origin <branch-name>

Fix commits

# Wrong commit message? No problem. Edit last commit message
$ git commit --amend -m "New commit message"

# Did you forget some changes and don't want a new commit?
# Add them to the last commit
# Warning: Try not to use it a lot 
$ git add .
$ git commit --amend --no-edit

See commit history

# Print commit tree in a pretty way
$ git log --oneline --decorate --graph --all

Save unfinished work

#Save all tracked files (Uncommitted)
$ git stash

#Save all tracked files with a message (Uncommitted)
$ git stash push -m "Great message"

# Include untracked and ignored files
$ git stash --all 

# List saved work
$ git stash list
> stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
> stash@{1}: On master: 9cc0589... Add git-stash

# Apply last saved work to the working directory
$ git stash pop

# Apply specific saved work to the working directory
$ git stash pop stash@{1}

# Clean stash
# Warning: Be sure you don't need anything else before running this command
$ git clear

Clean up a local repository

# A lot of branches that do no longer exist in the remote repository?
# Delete them from the local repository...
$ git fetch -p

Handling mistakes (Warning: use locally only)

# Unstage file
$ git reset HEAD -- <file-name>

# Unwanted changes now?, Sync with HEAD
$ git reset --hard HEAD

# Want to start over? undo n-last commits
$ git reset --hard HEAD~n

My git aliases

# I'm using Windows, so, instead of use bash aliases I use the git config option
git config --global alias.co=checkout
git config --global alias.br=branch
git config --global alias.cm=commit
git config --global alias.st=status
git config --global alias.unstage=reset HEAD --
git config --global alias.last=log -1 HEAD
git config --global alias.po=pull origin
git config --global alias.ps=!git push origin $(git current)
git config --global alias.current=branch --show-current
git config --global alias.pu=push origin
git config --global alias.pl=!git pull origin $(git current)

Migrating from JUnit 4 to JUnit 5 with Spring Boot 2.3.x

Edgar Cirilo — Tue, 27 Oct 2020 16:13:59 +0000

Recently, our team has moved to the last release of Spring (2.3.4). So we are taking advantage to move some projects unit tests to JUnit 5 due this is the default version since Spring Boot 2.2.x. Even though Junit 5 includes a vintage engine to support the JUnit 3 and JUnit 4 versions, we decided to fully migrate to JUnit Jupiter.

Dependencies

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-test</artifactId>
   <scope>test</scope>
   <exclusions>
    <exclusion>
     <groupId>org.junit.vintage</groupId>
     <artifactId>junit-vintage-engine</artifactId>
    </exclusion>
   </exclusions>
 </dependency>

Annotations

In the new version of JUnit, the base package has changed to org.junit.jupiter.api and some annotations have changed. Below you will find a table with the mapping for the most used annotations.

JUnit 4	JUnit 5
`org.junit.Test`	`org.junit.jupiter.api.Test`
`org.junit.Before`	`org.junit.jupiter.api.BeforeEach`
`org.junit.After`	`org.junit.jupiter.api.AfterEach`
`org.junit.BeforeClass`	`org.junit.jupiter.api.BeforeAll`
`org.junit.AfterClass`	`org.junit.jupiter.api.AfterAll`

Here is the API Documentation for the full list of annotations.

Exceptions

When using JUnit 4, we used the ExpectedException rule. However, it is no longer supported by JUnit 5. Fortunately, the Assertions API included in the Jupiter package have a handy way to assert the exceptions.

The assertThrows() method asserts that execution of the supplied executable throws an exception of the expectedType and returns the exception.

public static <T extends Throwable> T assertThrows(Class<T> expectedType, Executable executable)

Once the exception is returned, we can use the preferred Assertions API. In our case, we use AssertJ, so it's pretty similar to any other object.

@Test
public void exampleMethod_ThrowsCustomException_Fail() {
  CustomException expectedException =
  Assertions.assertThrows(CustomException.class, () -> {
    service.doSomething(ObjectDTO dto);
  });
  assertThat(expectedException).isNotNull();
  assertThat(expectedException.getErrorCode()).isEqualTo(50);
}

Spring

Spring provides some convenient annotations on behalf of JUnit 5.
@SpringJUnitConfig combines @ExtendWith(SpringExtension.class) and @ContextConfiguration into a single annotation. So, we have access to the configuration options through the @SpringJUnitConfig annotation.

@SpringJUnitConfig( classes = {TestConfig.class, SomeService.class}) 
public class SomeServiceTest {
    // class body...
}

@SpringJUnitWebConfig is pretty similar, with the difference that it includes @WebAppConfiguration besides @ExtendWith(SpringExtension.class) and @ContextConfiguration

@SpringJUnitWebConfig( classes = {WebConfig.class, SomeController.class}) 
public class SomeControllerTest {

    @Autowired
    private WebApplicationContext webAppContext;
    // class body...
}

You can read the official documentation of spring and spring boot to see the full list of annotations and a full description of each one.

Mockito

For Mockito, there are few changes to take into account. For previous versions, we used @RunWith but for JUnit 5 we have to use @ExtendWith instead:

@RunWith(MockitoJUnitRunner.class)
public class TheBestServiceTest {
    // class body...
}

Is now

@ExtendWith(MockitoExtension.class)
public class TheBestServiceTest {
    // class body...
}

Statics

Sometimes we need to mock some static methods. Usually, we use Powermock for this purpose. Nevertheless, Powermock won't be ported to the new version of JUnit. Fortunately, Mockito includes support for statics since the 3.4.x version.

In this case, we need to add some extra dependencies since spring-boot-starter-test only includes Mockito up to 3.3.3 version:

Dependencies

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>${mockito.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-inline</artifactId>
    <version>${mockito.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>${mockito.version}</version>
    <scope>test</scope>
</dependency>

Usage

Now we can mock static methods! As a matter of fact, this works pretty much as the normal methods. Ee only need to use a generic class supplied by Mockito; MockedStatic<T>, and use it within a try clause:

try (MockedStatic<ClassWithStaticMethod> mockedStatic =  Mockito.mockStatic(ClassWithStaticMethod.class)) {
      mockedStatic.when(ClassWithStaticMethod::someStaticMethod).thenReturn(new SomeDTO());
}

Conclusion

I think JUnit 5 comes with a different approach than its past version, something quite interesting, which can help us improve our unit tests. Despite being a big change, JUnit 5 makes sure to have backward compatibility to make migration more manageable. However, I highly recommend taking that step whenever possible.