8 Tools Java Developers should Learn

1. Groovy 

We use Groovy to write Java tests. Why is that? This is Java syntax, but some other rules, such as semicolons, variable types, and access modifiers, are optional. The latter is important for testing because, since access modifiers are not strict, your tests can read and assert state inside a class. For example, let’s assume the following class:

public class Foo { private String bar = null; public void setBar(String bar) { this.bar = bar; }}Copy the code

If you want to test that the setBar(String) method works, you can use Groovy’s convenience to read variable values. Java does not allow such operations (unless Java reflection is involved).

@Test public void test() { def foo = new Foo() foo.setBar("hello") Assert.isTrue(foo.bar.equals("hello")) //groovy Allows us to access the private variable bar}Copy the code

Powerful Assertions: Groovy provides a powerful variety of assertions, known as power Assertion statements. Groovy’s powerful assertions clearly show what happens when validation fails. In addition, it is more readable than Java.

    Assert.isTrue(foo.bar.equals("hello"));
Copy the code

You can write this in Groovy:

    assert foo.bar == "hello"
Copy the code

It displays a very clear description when an assertion fails:

    assert foo.bar == "goodbye" 
           |   |   | 
           |   |   false 
           |   hello 
           Foo@12f41634
Copy the code

Mocking: Dynamic Mocking frameworks such as EasyMock,PowerMock and Mockito are popular when using Java, Mocking frameworks that can be easily used in Groovy. Yeah!

2. Support REST

Our back end provides REST API services to create and manage accounts, and among the SDKS, our Java SDK provides a language-specific client model for simple interactions. Some of these SDKS also provide web pages to interact with the back end without writing code. In order for network frameworks to be interoperable, they must behave alike. So we need to create a series of HTTP-based tests. This is our compatibility testing tool. This project is maintained by our SDK engineers who are proficient in more than one language. So we needed cross-language testing tools, and thank goodness RESTFUL is here. Rest-assured is the Java DSL Domain-Specific Language for testing Rest services. It is easy to use and incredibly powerful even for developers who have never used Java. It provides advanced features such as detail configuration, filters, custom analysis, cross-site request forgery (CSRF), and OAuth 2.0. It provides very simple syntax: given-when-then. For example, let’s see how it validates that a request to send POST authentication information to the /login path returns a 302 status code:

    given() .accept(ContentType.HTML) .formParam("login", account.username)  
    .formParam("password", account.password) .when() .post(LoginRoute) .then() .statusCode(302)
Copy the code

You can see more restful testing in our TCK Repo

3. Cargo Plugin 

In order for our Java SDK to validate against TCK, we need to enable one of our Web services so that the tests can be executed on it. Logically, we need to test automatically every time we build, and the Gargo Plugin was born for this. Cargo simply encapsulates application containers in a standard way. We used Cargo to run our code effortlessly in different Servlet containers such as Jetty and Tomcat. We just need to configure the Cargo Maven2 Plugin in our POM file to start a Servlet container (Tomcat7) and compile the latest War package during the test phase, as you can see in our Servlet plug-in example.

4. Git 

What can we discuss about Git that you don’t know? To learn more About Git, check out their About page. Our Java SDK teams are all over the world and almost never sit next to each other. Git guarantees every line of code we write, and here are some great commands that save us a lot of time:

• Git mv -force foo.java foo. Java: Changing a file name in a case-sensitive file system is cumbersome, and this command will let Git know that foo. Java is renamed foo.java
• Git diff-tree — no-commit-id — name-only -r
  
  : View all files that were changed on the
  
  commit.
  
  
• Git diff -name -only SHA1 SHA2: lists all files that changed between SHA1 and SHA2 commits.
• To query for a string in a file’s commit history, create the search.sh file and paste the following code:

To query for a string in a file’s commit history, create the search.sh file and paste the following code:

    git rev-list --all $2 | ( 
        while read revision; do 
            git grep -F $1 $revision $2 
        done 
    )
Copy the code

The command can be executed in the following manner: sh./search.sh string_to_search file_where_to_search

5. GitHub 

GitHub doesn’t just host our Git project, it makes a huge contribution to making the code open source and available to the world. This encouraged people to experiment, to communicate, to practice, and greatly improved the quality of everyone’s projects and everyone’s technical level. GitHub allows us to follow up on our issues. Visitors can submit new requirements and report bugs. They can also be notified of the progress of our projects.

6.Maven

Maven is already well known. So I won’t go into a long explanation of why we use Maven for build management. However, I can share a few tips to make your Maven work better: Managing dependencies: In a multi-module project, you need to define each dependency in the <dependencyManagement> tag of the root PLOM.xml. Once you do this, all the underlying modules can be version-free. This way of managing dependencies (such as version upgrades) can be handled centrally and all the underlying modules are automatically identified. For example, in root pom.xml:

    <dependencyManagement> 
      <dependencies> 
        <dependency> 
            <groupId>io.jsonwebtoken</groupId> 
            <artifactId>jjwt</artifactId> 
            <version>${jjwt.version}</version> 
         </dependency> 
         ... 
      <dependencies> 
    <dependencyManagement>
Copy the code

Pom.xml for the underlying module:

<dependencies> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <! --> </dependency>... <dependencies>Copy the code

Prevent the underlying modules from compiling: We need all the underlying modules to be published at the same time, but how do we prevent one module (example) from being published? Simply add the following POM file to the module you don’t want to publish:

< plugin > < groupId > org. Apache. Maven. Plugins < / groupId > < artifactId > maven deploy - plugin < / artifactId > < version > 2.7 < / version >  <configuration> <skip>true</skip> <! This is the point --> </configuration> </plugin>Copy the code

Skip integration tests: We have many integration tests that take a long time to compile. These tests ensure that the back end as a whole works. During frequent local deployments, we changed the code many times for new features or bug fixes. You don’t need to run these tests every time you build locally, which slows down development. So we want to make sure that our Java SDK only performs integration tests while running on our CI server. You can do this by: root pom.xml file:

<properties> <skipITs>true</skipITs> </properties> ... <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <version>2.19.1</version> <configuration> <skipITs>${skipITs}</skipITs> <includes> <include>**/*IT. </includes> </configuration> <executions> <execution> <goals> <goal>integration-test</goal> <goal>verify</goal> </goals>  </execution> </executions> </plugin> </plugins> <build>Copy the code

So as you can imagine, all integration test files end with IT to make sure the configuration works, such as applicationit.groovy or i18nat.groovy. Then, if we want the integration test to run, we do the following build: mvn clean install -DskipITs=false