Test container is a third party Java library which offers to test or validate anything that can run in a Docker container. For Example, we can create lightweight database instances of  MySQL, PostgreSQL or Oracle database to test our data access layer code (DAO , Repositories). Similarly we can test our AWS cloud services like server less apps without actually using the cloud. We can do this with the help of LocalStack, a fully functional local AWS cloud stack.

Local Stack

LocalStack is a cloud service emulator. We can able to run AWS applications like Lambda, S3 entirely on your laptop or machine without connecting to a remote cloud provider.

Why It is needed ?

We can able to connect to AWS services like S3 from Java using their SDK’s. But here the problem is, if we wants to validate our code then we are need to connect cloud sandboxes using AWS SAM or anything like that. And While we access the cloud services, It is billable as well. Secondly we can not write unit test or integration test for this sources in a efficient way which would be a another downside of it. So In this article, we are going to learn to write unit testing for AWS S3 services with the help of Local stack and Test containers. Let’s dive into that. Cheers.

Prerequisite

• Java
• Maven
• Docker

Create a Spring initializer project

First, I am creating basic spring initializer project with Spring boot starter, Spring boot test and AWS SDK maven dependencies.

<dependency>
            <groupId>com.amazonaws</groupId>
            <artifactId>aws-java-sdk</artifactId>
            <version>1.11.163</version>
</dependency>

Creating AWS S3 Client

Second, now I am creating AWS S3 client with simple upload object functionality. Here I am validating whether the bucket is exist or not, followed by uploading an object into the S3 storage system.

package awsservicestutorial.client;

import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.model.ObjectMetadata;

import java.io.IOException;
import java.io.InputStream;
import java.net.URLConnection;
import java.nio.file.Files;
import java.nio.file.Path;

public class AwsS3Client {

    private final AmazonS3 amazonS3;

    public AwsS3Client(final AmazonS3 amazonS3) {
        this.amazonS3 = amazonS3;
    }

    public void uploadObject(final String bucketName, final Path path) throws IOException {

        isBucketExists(bucketName);

        final String filename = path.getFileName().toString();

        final ObjectMetadata metadata = new ObjectMetadata();
        metadata.setContentType(URLConnection.guessContentTypeFromName(filename));
        metadata.setSSEAlgorithm("AES256");
        metadata.setContentLength(Files.size(path));

        try(final InputStream stream = Files.newInputStream(path)){
            amazonS3.putObject(bucketName, filename, stream, metadata);
        }
    }

    private void isBucketExists(final String bucketName) {
        if(!amazonS3.doesBucketExist(bucketName)) {
            throw new IllegalStateException(String.format("Bucket %s does not exist", bucketName));
        }
    }

}

Local Stack and Test Container Dependencies

Add the following dependency to your pom.xml for using local stack and test container libraries.

        <dependency>
            <groupId>org.testcontainers</groupId>
            <artifactId>localstack</artifactId>
            <version>1.17.6</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.testcontainers</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>1.17.6</version>
            <scope>test</scope>
        </dependency>

Here I am using Junit-5 for unit testing the application. It is up to to decide whether Junit 5 or 4. We can do this with Junit 4 as well.

AWS S3 Client – Local Stack – Test Container – Create Unit Test

Creating unit test with local stack is really very simple. we just need to create local stack instance. This instance can act as AWS S3 services with the help of test container and docker. It will create a exact AWS mock in local or in our CI environment. This will reduce a lot money, since we don’t need to interact AWS cloud services during local development and testing.

package awsservicestutorial;

import awsservicestutorial.client.AwsS3Client;
import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3ClientBuilder;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.test.context.junit.jupiter.SpringExtension;
import org.testcontainers.containers.localstack.LocalStackContainer;
import org.testcontainers.junit.jupiter.Container;
import org.testcontainers.junit.jupiter.Testcontainers;
import org.testcontainers.utility.DockerImageName;

import java.io.IOException;
import java.net.URISyntaxException;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.Optional;

@Testcontainers(disabledWithoutDocker = true)
@ExtendWith(SpringExtension.class)
class AwsServicesTutorialApplicationTests {
    private static final String BUCKET_NAME = "test-bucket";
    @Container
    public final static LocalStackContainer LOCAL_STACK_CONTAINER =
            new LocalStackContainer(DockerImageName.parse("localstack/localstack:0.12.16"))
                    .withServices(LocalStackContainer.Service.S3).withEnv("DEFAULT_REGION", "us-east-1");
    private AmazonS3 amazonS3 = AmazonS3ClientBuilder.standard()
            .withEndpointConfiguration(LOCAL_STACK_CONTAINER.getEndpointConfiguration(LocalStackContainer.Service.S3))
            .withCredentials(LOCAL_STACK_CONTAINER.getDefaultCredentialsProvider()).build();

    private AwsS3Client awsS3Client;

    @BeforeEach
    public void beforeEach() throws IOException, InterruptedException {
        LOCAL_STACK_CONTAINER.execInContainer("awslocal", "s3", "mb", "s3://" + BUCKET_NAME);
        awsS3Client = new AwsS3Client(amazonS3);
    }

    @AfterEach
    public void afterEach() throws IOException, InterruptedException {
        LOCAL_STACK_CONTAINER.execInContainer("awslocal", "s3", "rb", "s3://" + BUCKET_NAME, "--force");
    }

    /**
     * First assert whether localstack is running!
     */
    @Test
    public void test_isLocalstackRunning() {
        Assertions.assertTrue(LOCAL_STACK_CONTAINER.isRunning());
    }

    @Test
    public void test_uploadObjectSuccess() throws URISyntaxException, IOException {

        awsS3Client.uploadObject(BUCKET_NAME, createPath());
        Assertions.assertTrue(amazonS3.doesObjectExist(BUCKET_NAME, "sample.csv"));
    }

    @Test
    public void tes_uploadObjectError() throws IOException, InterruptedException {

        LOCAL_STACK_CONTAINER.execInContainer("awslocal", "s3", "rb", "s3://" + BUCKET_NAME, "--force");
        Assertions.assertThrows(IllegalStateException.class, () -> awsS3Client.uploadObject(BUCKET_NAME, createPath()));
    }

    private Path createPath() throws URISyntaxException {
        return Optional.ofNullable(ClassLoader.getSystemResource("sample.csv").toURI())
                .map(Paths::get)
                .orElseThrow(IllegalArgumentException::new);
    }

}

• First, I am validating whether the local or CI machine having docker environment.
• Second, @Container creates the local stack container instance and mimic the AWS S3 as we are providing S3 as a service here. If you are using Junit-4, then you must use @ClassRule annotation here.
• During beforeEach() method, we are just creating the bucket in the S3 where as afterEach() method deletes the bucket after each test execution.
• You will need to create sample.csv file under test/resources directory for uploading into local stack S3.
• During upload test, once the file upload has been done, we can assert that using amazonS3.doesObjectExist method, whether the file has been successfully uploaded or not.
• And also we are validating after deleting the the bucket, whether it is throwing IllegalStateException exception or not.
• Finally In this way, we tested our AWS S3 client class effectively without connecting into AWS services.

AWS S3 Client – Local Stack – Test Container – Code Sample

• https://github.com/programeasily/aws-services-tutorial/blob/main/src/main/java/awsservicestutorial/client/AwsS3Client.java
• https://github.com/programeasily/aws-services-tutorial/blob/main/src/test/java/awsservicestutorial/AwsServicesTutorialApplicationTests.java
• https://github.com/programeasily/aws-services-tutorial

The post AWS S3 Client – Local Stack – Test Container appeared first on Program Easily.

             1. By Literal in Java

             2. By New Keyword

String Literal in Java

String Literals are very special in Java. We can create String object using double quotes as followed,

String message = "Hello ! I am a string";

The above code calls the intern() method of string first. Then the intern checks whether the same object is exists in pool or not!. If it is exist, it will return the same object reference. Otherwise It will create the new object in the pool and return the new object reference. Ultimately the string literal should be fast if we compare with new keyword since it will not create the new objects every time.

By New Keyword

We can create String object using new keyword as followed,

String message = new String("Hello ! I am a string");

The above code creates two string objects. It will create one object in Heap Memory directly and other in String Pool Area. And the reference will points to heap memory object.

Caution in String Compare

We have to use equals method of string to compare two strings always, not ==. Because == compares only the memory locations. But the equals method compare the memory location as well as the content of the stored objects.

String a = "Hello";
String b = "Hello";

// since literals re-use existing objects from the pool
System.out.println(a == b) // true

String c = new String("Hello");

// new keyword always creates new objects in the heap
// And == compares the memory locations not the exact
// content of the objects
System.out.println(a == c) // false

// Always use equals for comparison
// String class equals method checks the content of the 
// object as well
System.out.println(a.equals(c)) // true

Why String is Immutable

The rule to create any immutable object is, it’s state can not be changed after it is created. And String class designed to follow this rule. Even we could create N number of objects by following this rule. Let’s come to the point, why string is immutable ? The most correct answer is probably: Because the java language authors or designers figured it was a good idea. So that It will provide lot of benefits to us, Let’s see one by one.

Security

We have been mostly using string object in network connections, database connection URLs, usernames/passwords and etc. It it were mutable, we can change these parameters and runtime And which creates security issues.

Synchronization And Concurrency

We can say an object is thread safe, when multiple threads are operating on it but none of them is able to corrupt its state and object hold the same state for every thread at any point in time. Making String immutable automatically makes them thread safe by default thereby solving the synchronization issues.

Caching

when compiler optimizes your String objects, it sees that if two objects have same value (a=”test”, and b=”test”) and thus you need only one string object (for both a and b, these two will point to the same object)

Hash Code Caching

String object caches its hash code at the time of object creation which makes it the great candidate for hashing related operations because hash code doesn’t need to be calculated again which save us some time. This is why String is mostly used as Hash Map keys

Class Loading

We have been using String as an arguments for class loading. If mutable, it could result in wrong class being loaded (because mutable objects change their state).

Summary

1. Usually we design classes as immutable for them being thread safe and to optimize performance and memory consumption.

2. Security and Efficiency to be the primary design goals, then immutable strings are a means to meet those goals.

3. immutable objects in java are like copy-by-value, you can have 2 references to a String, but you should consider them 2 separate Strings since it’s immutable, and working with one of them won’t affect the other.

You May Also Like

• Java 8 Interview Questions for Experienced

The post String in Java – String Literal, String Pool, String Objects appeared first on Program Easily.