Every backend developer eventually faces the same question: which stack is best for my project?

With a background that spans both automation engineering and full-stack development, I've had the opportunity to work with various backend technologies. After spending considerable time in the Java ecosystem with Spring Boot, I became curious about other approaches to backend development. This curiosity led me to explore NestJS with Prisma in the JavaScript/TypeScript world and .NET Web API with Entity Framework Core in the C# realm.

What stood out was how each stack reflects its ecosystem’s philosophy: Spring Boot’s enterprise reliability, NestJS’s developer experience, and .NET’s deep integration with Microsoft tools. In this article, I'll share what I've learned about these three powerful approaches to building backend applications and interacting with databases.

Modern backend development is rich with frameworks, libraries, and tools that help engineers interact with databases, enforce best practices, and deliver production-ready applications:

1. Spring Boot + JPA + Flyway (Java ecosystem)

2. NestJS + Prisma (Node.js ecosystem)

3. .NET Web API + EF Core (C# ecosystem)

Each stack has its own philosophy, learning curve, and sweet spots. Whether you're a seasoned developer looking to expand your toolkit or a team lead evaluating technology choices for your next project, I hope my experience helps you navigate these options more confidently.

1. Spring Boot + JPA + Flyway (Java)

Overview

Spring Boot has been my go-to framework for years, especially for enterprise-grade applications. This battle-tested Java framework, when combined with JPA (Java Persistence API) for ORM and Flyway for database migrations, creates a robust foundation for applications that need to stand the test of time.

From my experience: Spring Boot shines when you're building systems that will evolve over many years with multiple teams contributing. The structure it enforces pays dividends as applications grow in complexity.

Features

• JPA/Hibernate ORM: Abstracts SQL operations into Java objects

• Flyway: Manages database schema evolution with version control

• Spring Boot autoconfiguration: Dramatically reduces boilerplate code

Example: Basic User Entity

Here's how a simple user entity looks in the Spring Boot world:

@Entity
public class User {
    @Id
    @GeneratedValue
    private Long id;

    private String username;
    private String email;
}

The repository interface makes database operations straightforward:

public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByUsername(String username);
}

And database migrations with Flyway are just SQL scripts with version numbers:

-- V1__create_user_table.sql
CREATE TABLE users (
  id BIGSERIAL PRIMARY KEY,
  username VARCHAR(50) NOT NULL,
  email VARCHAR(100) NOT NULL
);

Use Cases

• Enterprise banking, telecom, healthcare apps

• Large teams with structured requirements

• Complex domain-driven design implementations

• Systems requiring long-term maintenance

Strengths

• Rock-solid mature ecosystem with proven production reliability

• Excellent tooling from Spring Data to Spring Security

• Comprehensive documentation and massive community

• Strong integration with virtually any relational database

Challenges I've Faced

• The learning curve can be steep for newcomers to Java

• JPA/Hibernate sometimes generates surprising SQL queries that require tuning

• Configuration can get verbose for complex scenarios

• The development feedback loop is slower than with some newer stacks

2. NestJS + Prisma (Node.js)

Overview

When I first tried NestJS after years in the Java world, I was pleasantly surprised by its familiar structure (inspired by Angular) combined with the speed of the Node.js ecosystem. Paired with Prisma as the ORM, it creates a delightful developer experience with strong TypeScript type safety.

From my experience: NestJS + Prisma delivers incredible developer productivity while maintaining good architectural practices. The real magic is in Prisma's schema-driven approach and type generation.

Features

• Prisma schema: Acts as the single source of truth for your database schema and migrations

• Type-safe queries: Eliminates most runtime SQL errors with compile-time checking

• NestJS modules & decorators: Create a well-organized codebase with clear boundaries

Example: User Model

The Prisma schema is clean and intuitive:

model User {
  id        Int      @id @default(autoincrement())
  username  String   @unique
  email     String
  createdAt DateTime @default(now())
}

Services are concise and fully typed:

@Injectable()
export class UserService {
  constructor(private prisma: PrismaService) {}

  async findByUsername(username: string) {
    return this.prisma.user.findUnique({
      where: { username },
    });
  }
}

And migrations are as simple as:

npx prisma migrate dev --name init

Use Cases

• Startups and fast prototypes

• Real-time applications (chat, dashboards)

• Teams with JavaScript/TypeScript expertise

• Microservices and API-first applications

Strengths

• Lightning-fast development experience

• Excellent TypeScript integration with autocompletion for database queries

• Great for teams transitioning from frontend to full-stack

• Modern async/await patterns feel natural and clean

Challenges

• Ecosystem, while growing rapidly, isn't as mature as Java's

• Prisma has some limitations with complex queries and specialized database features

• Production deployment requires more careful consideration (Node.js runtime behaviors)

• Less battle-tested for extremely high-scale enterprise applications

3. .NET Web API + EF Core (C#)

Overview

Coming to .NET Web API after working with both Spring Boot and NestJS was an interesting experience. Microsoft's framework for building RESTful APIs, combined with Entity Framework Core as its ORM, feels like a middle ground - offering Java's robustness with some of TypeScript's developer experience benefits.

From my experience: .NET Core feels like it takes the best ideas from both worlds - Java's structure and TypeScript's expressiveness - while adding some uniquely powerful features like LINQ.

Features

• EF Core migrations: Built-in database schema evolution with intuitive tooling

• LINQ queries: Strongly-typed, composable query expressions that are a joy to write

• ASP.NET Core DI & middleware: Flexible request pipeline configuration

Example: User Entity

The C# entity is concise and readable:

public class User {
    public int Id { get; set; }
    public string Username { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
}

The DbContext defines your database structure:

public class AppDbContext : DbContext {
    public DbSet<User> Users { get; set; }
}

Migrations are generated and applied through the CLI:

dotnet ef migrations add InitialCreate
dotnet ef database update

Controllers are clean and well-structured:

[ApiController]
[Route("api/[controller]")]
public class UserController : ControllerBase {
    private readonly AppDbContext _context;

    public UserController(AppDbContext context) {
        _context = context;
    }

    [HttpGet("{username}")]
    public async Task<ActionResult<User>> GetUser(string username) {
        var user = await _context.Users.FirstOrDefaultAsync(u => u.Username == username);
        return user ?? NotFound();
    }
}

Use Cases

• Enterprise applications in Microsoft ecosystems

• Organizations using Azure or Windows servers

• Teams with C#/.NET expertise

• Applications requiring integrated Visual Studio tooling

Strengths

• First-class support from Microsoft with frequent updates

• LINQ provides an intuitive and powerful way to query data

• Excellent integration with Visual Studio's debugging and profiling tools

• Strong performance characteristics with relatively low verbosity

Challenges

• More resource-intensive than Node.js for equivalent workloads

• Some EF Core features like lazy loading have quirks that require attention

• The open-source community, while growing, is smaller than JavaScript's or Java's

• Breaking changes between major versions can create migration headaches

Head-to-Head Comparison

After working with all three stacks on similar projects, here's my comparison of key aspects:

I've found that the learning curve for Spring Boot is the steepest, particularly for developers without prior Java experience. NestJS strikes a good balance of structure and approachability, while .NET benefits from C#'s relatively straightforward syntax combined with powerful language features.

When it comes to database interactions, all three provide abstractions, but with different philosophies:

• JPA/Hibernate gives you the most control but requires more knowledge about how the ORM works under the hood

• Prisma is the most opinionated and "batteries-included" approach, making common operations extremely simple

• Entity Framework Core hits a nice balance with LINQ offering both simplicity and power

For team productivity, I've noticed that teams can typically deliver features faster with NestJS + Prisma initially, but as applications grow in complexity, the structure provided by Spring Boot becomes increasingly valuable. .NET teams, especially those already familiar with Microsoft technologies, often maintain consistent productivity throughout the project lifecycle.

Real-World Case Study: Building a User Management System

To make this comparison tangible, let's see how each stack would implement the same user management system. I'll walk through creating a system that supports:

• User registration (username + email + password)

• Fetching users by username

• Updating user information

• Deleting a user

This is a common requirement in many applications, and seeing the implementation differences will highlight the philosophy and approach of each stack.

1. Spring Boot + JPA + Flyway Implementation

Database Migration (Flyway)

-- V1__create_users_table.sql
CREATE TABLE users (
  id BIGSERIAL PRIMARY KEY,
  username VARCHAR(50) UNIQUE NOT NULL,
  email VARCHAR(100) UNIQUE NOT NULL,
  password VARCHAR(100) NOT NULL
);

Entity

@Entity
@Table(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;
    private String email;
    private String password;
}

Repository

public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByUsername(String username);
}

Service

@Service
public class UserService {
    @Autowired
    private UserRepository repo;

    public User register(User user) {
        return repo.save(user);
    }

    public Optional<User> findByUsername(String username) {
        return repo.findByUsername(username);
    }

    public void deleteUser(Long id) {
        repo.deleteById(id);
    }
}

Controller

@RestController
@RequestMapping("/users")
public class UserController {
    @Autowired
    private UserService service;

    @PostMapping
    public User register(@RequestBody User user) {
        return service.register(user);
    }

    @GetMapping("/{username}")
    public ResponseEntity<User> getUser(@PathVariable String username) {
        return service.findByUsername(username)
                .map(ResponseEntity::ok)
                .orElse(ResponseEntity.notFound().build());
    }

    @DeleteMapping("/{id}")
    public void deleteUser(@PathVariable Long id) {
        service.deleteUser(id);
    }
}

Spring Boot's implementation follows a clear layered architecture with distinct responsibilities for the Repository (data access), Service (business logic), and Controller (API endpoints). The approach is verbose but very structured, making it easy for new team members to understand the codebase.

2. NestJS + Prisma Implementation

Prisma Schema

model User {
  id       Int     @id @default(autoincrement())
  username String  @unique
  email    String  @unique
  password String
}

Run migration:

npx prisma migrate dev --name init

Service

@Injectable()
export class UserService {
  constructor(private prisma: PrismaService) {}

  async register(data: { username: string; email: string; password: string }) {
    return this.prisma.user.create({ data });
  }

  async findByUsername(username: string) {
    return this.prisma.user.findUnique({ where: { username } });
  }

  async deleteUser(id: number) {
    return this.prisma.user.delete({ where: { id } });
  }
}

Controller

@Controller('users')
export class UserController {
  constructor(private readonly userService: UserService) {}

  @Post()
  async register(@Body() data: any) {
    return this.userService.register(data);
  }

  @Get(':username')
  async getUser(@Param('username') username: string) {
    return this.userService.findByUsername(username);
  }

  @Delete(':id')
  async deleteUser(@Param('id') id: string) {
    return this.userService.deleteUser(Number(id));
  }
}

The NestJS implementation is more concise while still maintaining a clear structure inspired by Angular. The Prisma schema is particularly elegant, defining both the database structure and TypeScript types in a single file. The service methods are clean and to the point, leveraging TypeScript's async/await pattern.

3. .NET Web API + EF Core Implementation

Model

public class User {
    public int Id { get; set; }
    public string Username { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
    public string Password { get; set; } = string.Empty;
}

DbContext

public class AppDbContext : DbContext {
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }
    public DbSet<User> Users { get; set; }
}

Migration

dotnet ef migrations add InitialCreate
dotnet ef database update

Controller

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase {
    private readonly AppDbContext _context;

    public UsersController(AppDbContext context) {
        _context = context;
    }

    [HttpPost]
    public async Task<ActionResult<User>> Register(User user) {
        _context.Users.Add(user);
        await _context.SaveChangesAsync();
        return user;
    }

    [HttpGet("{username}")]
    public async Task<ActionResult<User>> GetUser(string username) {
        var user = await _context.Users.FirstOrDefaultAsync(u => u.Username == username);
        return user == null ? NotFound() : Ok(user);
    }

    [HttpDelete("{id}")]
    public async Task<IActionResult> DeleteUser(int id) {
        var user = await _context.Users.FindAsync(id);
        if (user == null) return NotFound();

        _context.Users.Remove(user);
        await _context.SaveChangesAsync();
        return NoContent();
    }
}

The .NET implementation strikes a balance between verbosity and expressiveness. The C# property syntax is concise, and the controller handles both data access and business logic in this simple example. In a more complex application, you would likely extract a service layer as well.

Side-by-Side Insights

• Spring Boot + JPA + Flyway: More boilerplate, but great for structured, enterprise projects.

• NestJS + Prisma: Concise, type-safe, developer-friendly. Perfect for startups.

• .NET Web API + EF Core: Balanced verbosity and power, shines in Microsoft ecosystems.

My Experience Using These Tech Stacks

Working with these three stacks across different projects has given me valuable hands-on insights into their strengths and use cases.

With Spring Boot, We built a major financial services product using a microservices architecture. While the initial learning curve was steep, the investment paid off in a robust system that scaled well as transaction volumes grew. The explicit nature of the code meant fewer surprises during maintenance phases, and the mature ecosystem provided solutions for most challenges we encountered.

Using NestJS with Prisma, I developed a backend for a startup's mobile app. The development speed was remarkable - we went from concept to functional API in weeks rather than months. The TypeScript integration and Prisma's database tools were particularly impressive, allowing us to iterate quickly as the startup's requirements evolved.

For an internal device farm backend, We chose .NET Web API with Entity Framework Core. The seamless integration with other Microsoft tools in our environment made this choice practical. LINQ queries simplified complex data operations, and the strong C# type system helped prevent many common bugs before they reached production.

What became clear across these projects is that each stack has its sweet spot. The right choice depends on your specific requirements, team expertise, and organizational context.

Final Thoughts: What I've Learned About Stack Selection

Having worked with all three of these stacks across various projects, I've developed some perspective on choosing between them. While I don't claim to be an expert in all these technologies, I'd like to share what I've observed from both my application development and automation work.

My Decision-Making Framework

Here's a simple framework I use when deciding which stack might be most suitable for a project:

Developer's Reflections: My Personal Journey with These Stacks

My journey with these technologies has been one of continuous learning and exploration. I want to share some honest reflections from my experiences with each stack.

Spring Boot: Learning Curve Adventures

My introduction to Spring Boot came after working with plain Java for several years. The difference was striking - where I had previously spent days configuring XML files and wrestling with application servers, Spring Boot let me focus on business logic.

Those first weeks involved a steep learning curve though! The complexity of dependency injection and the Spring ecosystem had me searching through documentation and Stack Overflow late into the night. I distinctly remember staring at a cryptic "bean not found" exception for hours before realizing I'd forgotten a simple annotation.

But eventually, things started to click. Building applications became more intuitive, and I grew to appreciate the structure that Spring Boot enforced.

NestJS + Prisma: A Pleasant Surprise

When I needed to create a dashboard for our test metrics, I decided to try NestJS with Prisma based on a colleague's recommendation. As someone who occasionally worked with Node.js for test scripting, I was curious but skeptical.

Setting up was surprisingly smooth. The TypeScript support was a game-changer for someone like me who values type safety when building test frameworks. The moment that stands out was watching Prisma generate models from our existing test database - it felt like magic compared to the manual ORM mapping I was used to.

The project that would have taken me months with Java was functional in weeks, giving me a new appreciation for what the right tools can do for productivity.

.NET: Breaking Out of My Comfort Zone

I avoided .NET for years, partly due to my background in open source tools. When a client project required it, I reluctantly agreed to build a test framework using .NET Web API and EF Core.

The Visual Studio experience was much better than I expected. LINQ queries made generating test data sets a breeze, and C# felt like a natural evolution from Java. The integration with Azure DevOps for our test pipeline was seamless.

A senior .NET developer on the team showed me patterns for mocking and testing I hadn't seen before, which I've since applied to other projects regardless of language.

What I've Taken Away

My journey with these stacks has taught me that being too dogmatic about technology choices limits growth. Each stack has introduced me to concepts and practices that have made me a better test automation engineer.

For others with a similar background looking to expand their skills:

• Spring Boot taught me architectural discipline

• NestJS showed me the value of developer experience

• .NET reminded me not to dismiss technologies without trying them

I'm still learning and exploring all three of these stacks. Rather than becoming an expert in one, I've found value in understanding the different approaches each takes to solving similar problems. This perspective has been invaluable when designing test frameworks that need to work across different application architectures.

What about you? If you've worked with these stacks, especially from a testing or automation perspective, I'd love to hear about your experiences in the comments.

Further Reading & Resources

To deepen your understanding of these stacks, here are some excellent resources that have helped me along my journey:

Spring Boot / JPA / Flyway

• Spring Boot Reference Documentation (Spring.io)

• Getting Started with Spring Data JPA

• Database Migrations with Flyway (Spring.io)

• Designing a REST API with Spring Boot (Spring.io Guides)

NestJS / Prisma

• NestJS Official Documentation (docs.nestjs.com)

• Prisma Getting Started Guide (Prisma.io)

• Building REST APIs with NestJS (NestJS.com)

• Building a REST API with NestJS and Prisma

.NET Web API / EF Core

• ASP.NET Core Web API Tutorial (Microsoft Learn)

• Entity Framework Core Documentation (Microsoft Learn)

• Building RESTful Services with .NET (Microsoft Learn)

• A Beginner’s Guide to Entity Framework Core (EF Core)

Test Automation is critical to modern software development, driving efficiency and faster feedback for API and UI testing. For our team, it started as a well-planned effort, but over time, our automation suite grew out of control—especially the UI tests built on Selenium WebDriver. With increasing delivery pressures, missing governance, and process gaps, we found ourselves dealing with an unmanageable regression suite, plagued by long execution times and flakiness.

This blog will share the lessons we learned, the challenges we faced, and the comprehensive steps we started taking to fix our automation framework. While we are still in the middle of this transformation, we have already seen improvements in the overall status of our regression suite.

The Problem: Growing Automation Pains

In the early stages, we practised in-sprint automation, and the approach worked seamlessly for some time. However, as our application and feature set expanded, so did our automation suite. We started encountering several significant issues:

1. Test Suite Bloat:

   • As the number of tests increased, so did the complexity and size of our suite, leading to longer execution times.

   • The reliance on Selenium-based UI tests made the suite especially prone to flakiness.

2. Flaky UI Tests:

   • Timing issues, dynamic elements, and inconsistent environments resulted in frequent false positives, eroding trust in automation.

3. Lack of Governance:

   • Without a clear test review process, redundant and low-value tests were added without fully understanding their impact on the suite.

4. Maintenance Overload:

   • The growing complexity meant we were spending more time on test maintenance and troubleshooting, often at the cost of writing new tests.

5. Environmental Challenges:

   • Ensuring a stable, consistent environment for test execution became difficult, leading to sporadic failures.

Recognizing that our test suite had become more of a burden than a help, we initiated a major overhaul to address these issues.

The Turning Point: Addressing Root Causes

We took a step back to analyze the situation and identify the root causes of our problems. Here’s what we found:

1. Over-reliance on UI Tests: Many validations were happening at the UI level when they could have been handled more effectively at the API or unit test level.

2. Redundant Tests Across Layers: Several tests duplicated functionality already covered by API or unit tests, making them unnecessary.

3. Inconsistent Test Design: The lack of modularity in test design meant that even minor changes to the application resulted in large-scale test failures, increasing maintenance costs.

4. Flaky Tests with No Immediate Fixes: Flaky tests were often ignored or rerun without addressing the underlying causes, which only compounded the issue over time.

The Fix: Transforming Our Automation Strategy

We knew that to regain control, we had to make some fundamental changes. While we are still in the process of implementing these improvements, here are the key steps we have undertaken so far:

1. Migrating UI Tests from Selenium to Selenide

One of our first major initiatives was moving our UI tests from Selenium WebDriver to Selenide. This shift provided several immediate benefits:

• Increased Stability: Selenide’s built-in synchronization and smart waiting mechanisms drastically reduced flakiness, making tests more reliable.

• Cleaner and Concise Code: The Selenide framework allowed us to write more concise and readable tests, cutting down on boilerplate code.

• Additional Features: Selenide offers features like automatic screenshots on failure, simpler handling of dynamic elements, and improved support for file downloads and uploads, which enhanced the overall robustness of our test scripts.

Although we’re still migrating tests, we have already seen improvements in the stability and reliability of the suite.

Selenide vs Selenium

2. Creating a Modular Page Object Library with Maven

To address the issue of maintainability, we created a separate Maven module dedicated to our Page Object Model (POM). This allowed us to:

• Reuse Across Environments: By creating a modular design, we can use the same Page Object library for both our stage and production environments, ensuring consistency.

• Simplified Updates: Any changes to the UI can be updated in the Page Object module without needing to touch the main test suite, making maintenance easier.

3. Test Data Service Using Spring Boot

One of the challenges we faced was the complexity of managing test data. To simplify this, we built a Test Data Service using Spring Boot, which generates the necessary test data through an abstracted business layer:

• Simplified API Interaction: Instead of making multiple backend API calls directly from the test scripts, our test data service acts as a central hub, orchestrating API calls and returning the required data in a clean, standardized format.

• Consistency Across Environments: This service helps ensure that test data remains consistent across environments, reducing flakiness due to data discrepancies.

Although we’re still fine-tuning this service, the improvement in test data consistency has been noticeable.

4. Test Execution Using Selenoid & Ggr

To improve our execution pipeline further, we adopted Selenoid and Ggr from Aerokube. These tools allowed us to run tests in browser Docker containers:

• Parallel Execution: By running tests in parallel across multiple containers, we’ve already begun reducing our total execution time.

• Efficient Resource Utilization: Selenoid provides lightweight, on-demand browser instances, allowing us to run tests on different browsers without maintaining a complex infrastructure.

• Scalability with Ggr: Ggr enables us to scale our test execution across multiple machines, improving overall throughput and test execution efficiency.

5. Optimizing the Test Pyramid

We realigned our test strategy to follow a test pyramid approach:

• API and Unit Tests as Priority: We moved as many tests as possible from the UI layer to the API and unit test levels. API tests are faster and more reliable, providing quicker feedback.

• Reducing UI Tests: UI tests were reserved only for critical end-to-end workflows, minimizing their impact on test execution time and stability.

This shift is ongoing, but the reduced emphasis on UI testing has already helped reduce execution time.

6. Integrating with ReportPortal for Smarter Failure Analysis

To streamline our test result analysis, we integrated ReportPortal:

• Enhanced Reporting and Triaging: ReportPortal’s comprehensive reporting allows us to track test results over time, making it easier to identify and prioritize issues.

• AI-Driven Failure Analysis: With ReportPortal’s AI-powered analysis, we can automatically detect patterns in test failures and categorize them for easier triaging. This significantly speeds up our debugging process and improves the quality of our automation.

Key Lessons Learned

1. Modularization Is Essential: Separating concerns into distinct modules, like the Page Object library and test data service, makes the test framework more maintainable and easier to extend.

2. Don’t Overload the UI Layer: Focusing too much on UI tests leads to longer execution times and increased flakiness. A balanced test pyramid with more API and unit tests improves both speed and stability.

3. Tools Matter: Migrating to Selenide and leveraging tools like Selenoid and Ggr improved the reliability and efficiency of our test suite by providing better browser management and parallel execution capabilities.

4. Data Management Is Critical: The Test Data Service helped streamline data management, making tests less dependent on direct API interactions and ensuring data consistency.

5. Smarter Failure Analysis: ReportPortal’s AI-powered failure analysis has started saving us significant time in debugging and improving our ability to fix flaky tests and recurring issues.

Conclusion:

Our automation journey is still ongoing, and while we haven’t yet completed all the changes, the improvements we’ve seen so far have been encouraging. Moving to Selenide, creating a Test Data Service, and using Selenoid for browser execution have already contributed to more stable and faster test runs. The integration with ReportPortal is helping us catch and fix issues more efficiently, even as we continue to optimize our test suite.

The key takeaway is that while the road to improving automation may be challenging, incremental improvements can lead to significant results over time. We are excited to continue on this journey and look forward to achieving a fully optimized and maintainable automation framework soon!

Happy Testing!

Writing clean, maintainable test automation code is crucial for ensuring long-term project success. One of the challenges test engineers face is managing the repetitive, boilerplate code needed for data models in test cases. Fortunately, Java 14 introduced a preview feature called 'Records', which was finalized in Java 16. Records provide a succinct and expressive way to define immutable data carriers, significantly reducing the amount of boilerplate code.

In this blog, we’ll explore how Java Records can enhance your test automation, making your code more concise, readable, and maintainable. We will also compare Records with Lombok, a popular library used for reducing boilerplate code in earlier Java versions.

For different examples of using Java Records with real-time APIs in test automation, you can check out my GitHub project here.

Understanding Java Records

Java Records are a special kind of class in Java designed to act as immutable data carriers. They can be thought of as nominal tuples, containing immutable fields where the compiler automatically generates methods like equals(), hashCode(), toString(), and accessors. This makes Records particularly suited for use cases where you need to store and retrieve data without much additional logic.

Key Features of Java Records:

• Immutability: Fields in Records are final, ensuring that the data can't be changed once created.

• Generated Methods: The Java compiler automatically provides implementations for equals(), hashCode(), and toString() methods.

• Accessor Methods: Instead of traditional getters, Records use accessor methods that match the field names.

Example of Java Record

Here’s a simple example of a User record:

public record User(String username, String password) {}

This one line of code is equivalent to writing a traditional class with private final fields, a constructor, and several utility methods like equals() and hashCode().

Why Use Java Records in Test Automation?

Test automation often involves setting up test data models, such as user credentials, API requests, or database entities. These models tend to be simple data holders without much business logic, making them perfect candidates for Records.

Benefits of Java Records in Test Automation:

• Reduced Boilerplate: Simplifies the code by auto-generating common methods, eliminating the need for manual coding of accessors and other methods.

• Improved Readability: Compact syntax helps focus on the logic of the test rather than unnecessary class definitions.

• Ease of Maintenance: Less code means fewer points of failure and easier maintenance over time.

Example: Simplifying Test Code

Let’s consider a test scenario for verifying login functionality. Here’s how you might implement it without using Records:

Without Records

public class User {
    private final String username;
    private final String password;

    public User(String username, String password) {
        this.username = username;
        this.password = password;
    }

    public String getUsername() {
        return username;
    }

    public String getPassword() {
        return password;
    }
}

And use it in a test like this:

@Test
public void testLogin() {
    User user = new User("testuser", "testpassword");
    loginPage.login(user.getUsername(), user.getPassword());
    assertTrue(dashboardPage.isLoggedIn());
}

With Records

By using Records, the code becomes much more concise:

public record User(String username, String password) {}

And use it in a test like this:

@Test
public void testLogin() {
    User user = new User("testuser", "testpassword");
    loginPage.login(user.username(), user.password());
    assertTrue(dashboardPage.isLoggedIn());
}

In this case, the test logic remains the same, but the code is simplified, making it easier to read and maintain.

Real-World Example: Testing an E-commerce Application

Consider a more complex test scenario in which we’re testing an e-commerce application. Here, we need to represent a Order containing an order ID, user details, and a list of items.

Without Records

Without using Records (or Lombok), the Order class might look like this:

public class Order {
    private final String id;
    private final User user;
    private final List<Item> items;

    public Order(String id, User user, List<Item> items) {
        this.id = id;
        this.user = user;
        this.items = items;
    }

    public String getId() {
        return id;
    }

    public User getUser() {
        return user;
    }

    public List<Item> getItems() {
        return items;
    }
}

With Records

Using Records simplifies this model dramatically:

public record Order(String id, User user, List<Item> items) {}

In a test, you could then represent and work with Order like this:

@Test
public void testOrderProcessing() {
    User user = new User("testuser", "testpassword");
    List<Item> items = Arrays.asList(new Item("item1", 2), new Item("item2", 1));
    Order order = new Order("order1", user, items);

    orderPage.placeOrder(order);
    assertTrue(orderPage.isOrderPlaced(order.id()));
}

Comparing Java Records with Lombok

Before Java Records were introduced, developers often turned to Lombok to reduce boilerplate code. Lombok provides annotations like @Data, @Getter, and @Setter, which automatically generates common methods at compile time. However, Records, being a built-in language feature, come with their advantages and trade-offs.

Key Differences:

• Java Version:

  • Records: Available from Java 16 onward.

  • Lombok: Compatible with older Java versions.

• Immutability:

  • Records: Fields are inherently final, ensuring immutability.

  • Lombok: Can generate mutable objects unless explicitly marked with @Value for immutability.

• Dependencies:

  • Records: Native to Java—no external dependencies.

  • Lombok: Requires adding an external library to your project.

• Tooling Support:

  • Records: Supported by most modern IDEs and tools since they are part of the core Java language.

  • Lombok: Some IDEs may have compatibility issues due to Lombok's bytecode manipulation.

When to Use Records vs. Lombok:

• Use Records if:

  • You're using Java 16 or later.

  • You need simple, immutable data carriers with minimal custom behaviour.

• Use Lombok if:

  • You’re working with older Java versions.

  • You need mutable objects or more flexibility in the generated code.

Conclusion

Java Records are a powerful tool for test automation, especially when working with simple, immutable data models. They reduce boilerplate code, enhance readability, and make tests easier to maintain. While Lombok remains a great option for those using earlier Java versions or needing additional flexibility, Records provides a cleaner, more efficient approach for modern Java applications.

When writing test automation in Java 16 or later, consider using Records to simplify your data model representations and improve the overall maintainability of your codebase.

The Turning Point

Recognizing that my productivity was taking a hit due to excessive screen time, I knew I needed to regain control. I decided to give Regain a try, a mobile app designed to manage and monitor mobile usage. The change was immediate—and it went beyond just limiting screen time.

How "Regain" Works

The app is built around empowering users to regain control over their digital habits. It offers features like daily time limits for specific apps, scheduled notifications, and usage tracking. But what sets it apart is how it addresses the psychological triggers that keep us hooked to our phones. Here’s how it worked for me:

• Scheduled Notifications for Mindful Breaks: Regain allows me to schedule notifications that remind me to take breaks productively. Instead of aimlessly browsing social media during these breaks, I now spend that time on healthier activities—such as quick stretches, meditation, or a walk. This has helped me rewire how I approach relaxation, and it has had a noticeable effect on my mental clarity.

• Dopamine and Cortisol Control: The constant consumption of short, entertaining content—like reels and shorts—triggers dopamine spikes, which leads to the urge for more content, ultimately creating a cycle of addiction. At the same time, the stress of falling behind on work or personal goals releases cortisol, the "stress hormone." Regain has helped break this cycle. By limiting my screen time and reducing over-stimulation, I’ve been able to stabilize both dopamine and cortisol levels. This balance has not only improved my focus but also reduced feelings of anxiety and stress.

My Experience

Before Regain, I wasn’t fully aware of how much time I was losing to mindless browsing. The app's ability to set daily usage limits has transformed my routine. Now, I’m greeted with a reminder when I approach my limits for apps like Instagram and YouTube, encouraging me to shift my focus back to work or more meaningful activities.

In just a few weeks, I've noticed profound changes—not just in my productivity but also in my overall mood. With less time spent on social media, I’ve found myself less agitated and more centred throughout the day.

Key Features That Made a Difference

• Custom Time Limits: Setting daily caps on apps helped me curb unnecessary screen time. I could limit apps like YouTube and LinkedIn without having to cut them off entirely.

• Scheduled Notifications: This feature allowed me to receive timely reminders to pause and engage in more mindful activities, preventing burnout.

• Dopamine Regulation: By reducing quick-hit content consumption, I’ve become less dependent on constant entertainment and more focused on long-term goals.

• Cortisol Reduction: Less time spent in front of a screen helped reduce stress, allowing me to manage my workload without feeling overwhelmed.

Final Thoughts

Since I started using Regain, I’ve regained control of both my screen time and mental well-being. Cutting back on social media and video reels has reduced my dopamine dependency, and in turn, my cortisol levels have decreased, leaving me feeling more balanced and less anxious. I’m more productive, focused, and able to handle the demands of my role with greater ease.

If you’re looking for a way to take charge of your time and improve your focus, I highly recommend trying Regain. For me, it has been the key to better time management, increased productivity, and improved mental health.

The Need for an On-Demand API Health Check Page

In our project, managing a growing number of backend services across multiple environments (development, multiple staging environments, UAT) became a significant challenge. We needed a way to quickly check the health of services without relying on constant, real-time monitoring. Instead, we were looking for a simple, on-demand health check solution that allowed our team to manually verify the status of services at key moments, such as before or after deployments, without unnecessary overhead.

This approach would act as a first quality gate—a quick check to ensure that all critical services are running as expected before moving on to more rigorous testing or deployments. We didn't need a complex, continuous monitoring tool with alerting, but rather an easy way to manually trigger health checks for services when necessary. This is especially useful in scenarios like:

• Pre-deployment checks to confirm that services are functioning properly before pushing updates.

• Post-deployment checks to verify that new releases haven't broken any dependencies or services.

• On-demand troubleshooting when we see issues with the application, allow us to quickly check the availability of services.

After exploring various solutions, we found that many enterprise-grade tools such as Dynatrace or Prometheus were too complex and offered features we didn’t need, like constant uptime monitoring and alerts. What we needed was a simpler, open-source solution to display API statuses when requested.

That’s when we came across the API Health Checker Dashboard. This tool provided exactly what we were looking for:

• On-demand health checks that allow us to see the current status of our services whenever we need to, without requiring continuous polling or monitoring.

• A centralized view of all services across environments, making it easy for team members to verify the health of critical services before proceeding with further tasks.

Let’s have a detailed breakdown of how this tool works under the hood, its key features, and why it stands out in comparison to other monitoring solutions.

Key Features of API Health Checker Dashboard

1. Real-Time Monitoring: The dashboard continuously monitors the availability of backend services by sending periodic requests to predefined health-check endpoints. It refreshes every "x" seconds (configurable), allowing near-instant visibility into the status of APIs.

2. Multi-Environment Support: You can maintain multiple environments such as production, staging, or development by configuring separate JSON files. This ensures that each environment’s health is tracked independently within the same dashboard.

3. Mobile-Friendly Interface: The dashboard's UI is responsive and can be accessed on both mobile and web browsers.

4. No CORS Issues: The tool includes a proxy layer to prevent CORS (Cross-Origin Resource Sharing) issues, ensuring smooth communication between different services across domains.

5. Demo Page Available: A live demo is hosted here, where you can interact with a sample dashboard to see the tool in action.

How It Works - Technical Breakdown

The API Health Checker Dashboard is built using Node.js and primarily operates by making HTTP requests to the health-check endpoints of the services you wish to monitor. Here’s a step-by-step breakdown of how it functions internally:

1. Polling Mechanism:

   • The system makes use of a polling mechanism, sending periodic requests to each service’s health-check endpoint. The interval for these requests can be set in the configuration file (default is every 30 seconds).

   • The system expects the endpoints to return an HTTP status code. If the status is in the 200-range, the service is considered “available.” Any other status code, or a timeout, marks the service as “unavailable.”

2. Service Configuration:

   • Services to be monitored are defined in JSON configuration files located in the config directory. This is where you list your backend services’ health-check URLs.

   • For each service, you can provide:

     • Name of the service (for display on the dashboard)

     • Health-check endpoint (URL)

     • Environment, Description and other details as below

         //config/qa-config.json
         [
           {
             "name": "Employee Service",
             "description": "This service will be using for all the employee management functions.",
             "id": "employee",
             "environment": "qa",
             "url": "http://dummy.restapiexample.com/api/v1/employees",
             "contact": "osanda@maxsoft.com"
           },
           {
             "name": "ToDos Service",
             "description": "This service will be using for all the todo management functions.",
             "id": "todo",
             "environment": "qa",
             "url": "https://jsonplaceholder.typicode.com/todos/1",
             "contact": "osanda@maxsoft.com"
           }
         ]
       

3. Frontend Interface:

   • The user interface is built using standard web technologies—HTML, CSS, and JavaScript—allowing it to be highly customizable. It provides a dashboard view where all services are listed, showing their real-time status.

   • Each service is displayed as a tile with either a green or red status indicator, representing "healthy" or "unavailable" services. The status updates are fetched using AJAX calls, allowing for real-time updates without the need to refresh the page.

4. Handling CORS Issues:

   • Many API health-check tools face CORS issues when making requests across different domains. To overcome this, the API Health Checker Dashboard includes a proxy layer. This proxy acts as an intermediary between the dashboard and the health-check services, routing requests in such a way that bypasses the CORS restrictions.

5. Real-Time Data Flow:

   • The Node.js backend sends requests to the specified endpoints and handles the incoming HTTP responses. The results are then passed to the front end, which updates the status tiles accordingly.

   • The update frequency (i.e., the polling interval) can be adjusted based on your preference by modifying the configuration settings.

6. Deployment:

   • The tool is designed to be easy to deploy. After cloning the repository, you can install the necessary dependencies using npm install, then run the dashboard with npm run dev. The dashboard will be accessible at http://localhost:5000 by default.

   • You can also deploy this solution to a cloud platform or any server capable of running Node.js applications.

   • Our apps are deployed to the Pivotal Cloud Foundry environment, hence we cf push to deploy the health check app in a respective environment.

Comparing with Other Similar Solutions

1. Dynatrace

   • What it offers: Dynatrace is a powerful all-in-one monitoring tool that provides deep observability across applications, infrastructure, and cloud environments. It uses AI to detect anomalies and offers advanced alerting, real-time monitoring, and root-cause analysis.

   • Why it wasn't the right fit for staging: While Dynatrace excels in production with its full-scale monitoring and alerting capabilities, it can be overkill for non-production environments. Its complexity and cost don’t justify the overhead for staging environments, where we primarily need on-demand health checks rather than continuous monitoring.

2. Prometheus

   • What it offers: Prometheus is an open-source monitoring system designed for capturing metrics, which includes querying and alerting features. It’s highly flexible and customizable, especially when paired with Grafana for visualization.

   • Why we didn’t choose it: Prometheus requires significant setup and maintenance, and it’s tailored more for capturing time-series data and long-term metrics, which adds unnecessary complexity. We wanted a lightweight solution for quickly verifying API health, and setting up Prometheus with custom dashboards and metrics would be overkill for our needs.

3. Pingdom

   • What it offers: Pingdom is well-known for uptime monitoring, providing real-time alerts when services go down. It’s widely used for website and API uptime checks and offers easy-to-read dashboards.

   • Why it wasn’t ideal: While Pingdom is great for production environments, it comes with subscription costs that aren’t justified for non-production environments. Furthermore, its primary focus on uptime and real-time alerts isn't necessary for the on-demand checks we need in testing environments.

4. Atlassian Status Page

   • What it offers: Atlassian’s Status Page is a communication tool that allows companies to inform users about the operational status of their systems. It’s more focused on status reporting and sharing that information with stakeholders, rather than on real-time technical monitoring.

   • Why we didn’t choose it: This tool is mainly for communication with external stakeholders about service status rather than an internal tool for health-check verification. We needed a tool focused on internal, quick health checks that developers & testers could use during stage environment testing.

Final Thoughts

Using the API Health Checker Dashboard has allowed us to create a unified and reliable view of our API services' health without the need for complex configurations or expensive software. It’s a great fit for teams that require lightweight, real-time API monitoring without the overhead of larger, more complex tools. For those looking for an open-source alternative, I highly recommend trying this solution.

For more technical details and to get started, you can explore the project on GitHub

Discovering a bug in a production environment is a nightmare scenario for any test lead. It’s stressful, potentially embarrassing, and often leads to immediate scrutiny of the testing team. However, it's crucial to recognize that software testing is inherently complex, and even the most thorough procedures cannot catch every bug. This article provides best practices for test leads to manage such situations professionally and turn them into learning opportunities for future improvements.

1. Don’t Panic: Stay Calm and Focused

The first and most important step when a bug is found in production is to remain calm. Panicking will not solve the problem and could cloud your judgment, leading to hasty decisions. Stay composed, assess the situation, and remember that it’s an opportunity to show how resilient and resourceful your team can be in crisis management.

• Pro Tip: Take a moment to assess your emotional state and ensure your communication is clear and collected. Leaders set the tone for the team.

2. Gather All Necessary Information

Before rushing to conclusions or taking any immediate action, gather detailed information about the bug. This includes identifying:

• The nature of the bug (e.g., what is causing it?)

• The system components affected

• The severity and impact on users (how critical is it?)

Understanding the bug’s scope allows for proper prioritization and ensures that the fix addresses the core issue without introducing new ones.

• Actionable Tip: Create a standardized checklist for bug discovery in production that your team can quickly fill out in these scenarios.

3. Communicate Effectively

Communication during such incidents is critical. Inform all relevant stakeholders—developers, product owners, support teams, and clients if necessary—about the issue as soon as it is identified. Be transparent and provide frequent updates on the investigation and resolution progress.

• Effective Communication Plan:

  • Send an initial notification about the bug, including its severity and potential impact.

  • Assign a point of contact for all updates and progress tracking.

  • Schedule regular updates, even if no significant progress is made.

Maintaining transparency prevents speculation and ensures everyone is on the same page.

4. Conduct a Root Cause Analysis (RCA)

Once the immediate crisis has been mitigated (e.g., the bug is patched or a workaround is in place), conduct a thorough Root Cause Analysis (RCA) to determine why the bug was missed during testing. Several methodologies can help pinpoint the cause:

• The 5 Whys: Ask “why” repeatedly until you reach the fundamental reason behind the bug’s occurrence.

  • https://www.lean.org/lexicon-terms/5-whys/

  • https://www.mindtools.com/a3mi00v/5-whys

• Fishbone Diagram: Visualize the different factors contributing to the issue, such as testing gaps, communication failures, or overlooked requirements.

  • https://asq.org/quality-resources/fishbone

• Fault Tree Analysis: Break down the problem into different potential causes, including human error or technical failures.

  • https://fiixsoftware.com/glossary/fault-tree-analysis/

Example RCA: Let’s say an application crashes when users access a specific feature. Using the 5 Whys technique might reveal that:

• The crash was caused by a feature overload.

• The feature wasn’t optimized for large data volumes.

• Testing didn’t include large data volumes.

• The testing team wasn’t informed about this requirement due to a communication gap.

Root Cause: Requirements were not clearly communicated.

5. Implement Corrective Actions

Based on the RCA, take corrective actions to avoid future production issues. This could involve:

• Updating test cases to ensure better coverage.

• Improving communication between product and testing teams.

• Enhancing the bug-tracking process to include new scenarios or edge cases.

• Providing additional training to team members on identifying high-risk areas.

By doing so, you’ll turn this production bug into a valuable learning opportunity that strengthens your process moving forward.

6. Learn from the Experience

Every bug is a chance to improve. Treat it as an opportunity to analyze and refine your team’s processes. Document lessons learned from both the technical and managerial perspectives to prevent future issues. Additionally, encourage knowledge sharing within the team, so everyone understands what went wrong and how it can be prevented in the future.

• Suggested Approach: Conduct a postmortem meeting with all stakeholders and publish a summary report that outlines the lessons learned, corrective measures, and updated procedures.

7. Foster a Culture of Shared Responsibility

Finally, it's important to cultivate a culture where quality is a shared responsibility. Everyone involved in the software development lifecycle—from developers to product managers—has a role in ensuring that the product is bug-free. Foster a blameless culture where the focus is on collaboration, not finger-pointing.

• Blameless Retrospectives: Encourage teams to discuss production issues openly without fear of blame, focusing instead on how processes can be improved as a collective.

Bonus: Prevention Strategies and Tools

While this article focuses on how to handle bugs once they’re found in production, prevention is always better than cure. Here are some strategies to minimize the chances of bugs making it to production in the first place:

• Automated Testing: Integrating automated unit and regression testing into your continuous integration pipeline helps catch bugs earlier.

• Load Testing: Ensure that features are tested under the conditions they’ll face in production, including large data volumes or high traffic.

• CI/CD Pipelines: Continuous Integration/Continuous Deployment tools help ensure that code is thoroughly tested before reaching production, reducing the likelihood of bugs.

Conclusion:

Finding a bug in production is not an ideal scenario, but it doesn’t have to be a disaster. By staying calm, gathering information, communicating clearly, and learning from the experience, test leads can turn this situation into an opportunity for growth and improvement. Remember, a great team is not defined by its ability to prevent all bugs but by how effectively it handles them when they occur.

By fostering a culture of shared responsibility, encouraging open communication, and continually refining your processes, you can ensure that future production bugs are minimized and managed with confidence.

What is Generative AI Kata

"Kata" is a Japanese word often used in martial arts to describe practicing different patterns, either alone or in small groups, to memorize and perfect them.

Generative AI Kata is an immersive journey into the realm of artificial intelligence, where you'll delve into the art of creating, training, and fine-tuning AI models to generate novel and creative outputs. It's not just about coding; it's about unleashing the full potential of AI to drive innovation and solve real-world challenges.

Why should anyone attend Kata

Deepen our AI Expertise: Whether you're an experienced AI practitioner or just starting, Generative AI Kata offers a unique opportunity to deepen our understanding and master the latest techniques in AI development.

Hands-on Exploration: Given an interactive experience like no other! We can dive into hands-on exercises and start an exciting journey of discovery with our peers.

Collaborative Energy: We can join fellow tech enthusiasts, share ideas, and work together on exciting AI projects. Generative AI Kata is more than just an event; it's about a shared passion for exploring, learning, and growing together.

Stay Ahead of the Curve: In today's fast-changing tech world, keeping up is essential. Generative AI Kata gives us the knowledge and skills to stay at the cutting edge of AI innovation.

How it works

Step 1: The panel explains the problem statement to all participants. Participants can ask any questions or request clarifications.

Step 2: Participants are divided into teams of 3-5 members.

Step 3: Teams will go to their discussion rooms and brainstorm different possible solutions.

Step 4: The team will come up with the best solution and present it to the panel in the open room. They should be ready to explain or answer any questions during this Challenge phase. This process is managed in a round-robin style by a facilitator.

Step 5: Finally, the jury will discuss and announce the top 2 winning solutions (teams) and give out rewards.

Challenge

Below is the problem statement given to all participants during the Kata, along with the expected solution and artifacts that need to be delivered.

Problem Statement:

Our QR code generator app, despite its long-standing presence and large user base, is facing issues due to its outdated legacy monolithic application using Winforms. The lack of documentation and turnover in personnel has further complicated the modernization process of the application. This is hindering our market competitiveness and affecting the app's performance, scalability, and maintainability.

Below is the current application, developed in WinForms - a .Net-based desktop application.

Major features:

• Generate a QR code for the given URL

• Embed the image as a logo in the generated QR code

• Provision to download and save the image

• Capability to display the logo background with various shapes and colors

Source:https://ardeshirv.github.io/QrCodeGeneratorWithLogo/

Solution Required:

The solution involves a strategic approach of static whitebox reverse engineering. This includes analyzing the current state of the application, defining the desired state, and conducting a gap analysis. The key deliverables from this process will be a comprehensive documentation of the current state of the application and a detailed gap analysis report. This will help us enhance the performance, scalability, and maintainability of the app, thereby improving our competitiveness in the market.

Also, a major point to note is that we should leverage GenAI to accomplish these tasks. The submitted solution will be evaluated based on the below criteria.

• Prompt Effectiveness & Techniques Used

• Less Human Intervention

• Context given to LLM

• Output Expectations

• Design Patterns used

• Tech Stack-specific Output

• And other documentation

How we solved it

As planned, each team should consist of 5-6 members with roles such as Architect, Lead Developer, Automation Engineer, Product Owner, and Testing Engineer. However, due to unforeseen circumstances, our Architect and Lead Developer didn't join the session. This left us with just myself (Lead Automation Engineer/SDET) and two other colleagues, both of whom are Senior Automation Engineers. Also, there is no Product Owner assigned to our team!

We have only 2 hours to complete the major task of modernizing the given legacy and monolithic application. Except for myself, the team has limited knowledge of application architecture and development. We accepted the challenge and took on multiple roles to complete it.

While the requirement was to use GenAI to generate the solution and documentation, we used EPAM's own DIAL(a tool similar to ChatGPT with access to multiple LLM models from different vendors) as our tool.

• Acting as a Business Analyst:

  • We began brainstorming on the given application. We used the desktop application as a user to understand its functionality. From this, we identified the necessary features for our new application.

  • With the necessary functionalities as input, we used prompt engineering to define the high-level requirements for our new application. We included columns such as Requirement ID, Requirement Description, and Priority in the prompt, and the LLM successfully generated the output as we intended.

  • We even included features for the performance, security, and usability requirements of the application.

  • After this, we gathered all the data into a table format and created our final requirement document.

  • The final document we submitted to the Jury is available here on GitHub for reference.

  • The exported prompts from GenAI are available here. This includes our entire conversation with the AI acting as a business analyst.

• Acting as an Architect & Lead Developer

  • This was the most challenging part of the entire session for us.

  • We provided the LLM with all the technical details about the application, the challenges we faced with the monolith and our goals. We aimed to gather information on a new architecture for the app that would be modular, scalable, and efficient using the latest technologies.

  • Based on the prompts and AI output, we decided to build or migrate the application into different modules, consisting of front-end and back-end layers.

  • For the backend, we chose ExpressJS and began with prompts to obtain the necessary backend logic for the application. We used the existing npm library qrcode and added a single route for generating the image in the app.js.

  • With the core back-end functionality working well, we focused on building the front-end application as a separate module. Using the prompts, we chose ReactJS as our solution and obtained the necessary code to build a simple web application.

  • After we integrated and started both apps, we encountered CORS errors, and the application wasn't working. With the help of AI, we resolved the issue by adding a new npm dependency, cors, and some new configurations for the backend app.

  • Voila! Now both the frontend and backend apps are integrated successfully, and the application is running smoothly in a browser on our local systems. Finally, we can pass a URL to the QR code generator app, and it generates the image as expected.

  • We improved the app's appearance and added new features like image download and disabling the URL textbox until the user enters text. All these enhancements were made using prompt engineering via AI.

  • We even generated the high-level architecture diagram and the README.md file for the repository using only prompts.

  • Our application architecture is shown below. We used AI-generated code snippets along with PlantUML to create this diagram.

    

  • The final GitHub code repository we submitted to the Jury is available here for reference. It includes both front-end and back-end code.

  • The exported prompts from GenAI are available here. This includes our entire conversation with the AI acting as an Architect and Developer.

• Acting as a Test Lead & Test Engineer

  • While developing the application, we also used similar prompting techniques to generate the artifacts for testing.

  • After setting the application context and going through multiple iterations of prompts, we created a detailed Test Strategy document. You can refer to the final document here.

  • Developing all the features within the given time frame wasn't possible. So, we focused on some critical features and created an MVP release for the migration. Based on these prioritized features, we created a test plan to execute the testing activities and validate the application.

  • Initially, the generated content was generic, but we explicitly changed our prompts to include the necessary information for some sections. As a result, our final Test Plan is ready.

  • Next, we created the required test cases to validate the application and compiled them in a table with all the necessary columns.

Demo

Once we finished developing our application, we manually validated the scenarios. We didn't have time to prepare a deck with our design and artifacts, so we used the README.md file as our presentation to the jury. We explained our approach to modernizing the application, our different roles, and how we achieved the desired results using Generative AI and prompt engineering. The jury had some questions and clarifications. They also asked us to show the documents we created and the prompts in the DIAL. We explained and demonstrated them to the best of our knowledge.

Here is the application that we developed.

Lessons Learned

Winning the Kata does not mean that I and my team made everything perfect and implemented all requirements. Not at all. Given the 2 hrs time, we needed to make trade-offs and skip certain implementations for the application.

• We missed generating some important documents like Gap Analysis for the given application.

• We couldn't implement some of the existing functionalities like adding a logo to the image, shapes, and colors for the logo, etc.

• We focused only on the core functionality of generating and downloading the QR image, providing the simplest and most effective solution possible.

• It also took some time to get to know each other and plan the activities for the task, as the team members were new and unfamiliar with each other. We needed time to distribute the tasks and understand each other's roles in the session.

• Despite these issues, we used the given time to create a minimum viable working product for the jury.

• Other teams also worked very hard and gave great presentations. One team used Python for their app and built all the functionality. Another team generated detailed documentation but did not create a working solution. Each team had its own unique experience.

Conclusion

It was great to be part of this Kata and collaborate with others to focus on a common goal, which helped us to expand our capabilities. Despite team constraints and limited time, we successfully created a modular, scalable application. We leveraged Generative AI and used prompt engineering, generated documentation, architecture diagrams, and test plans. Our solution focused on core functionality and effective collaboration, leading to our victory.

Chaos Engineering has emerged as a critical discipline in the world of software development, helping teams build more resilient and robust systems. Several tools have been developed to facilitate chaos engineering practices. This article provides a comparative analysis of some of the most popular chaos engineering tools available today.

1. Chaos Monkey:

Chaos Monkey is a resiliency tool developed and used by Netflix. It follows the principles of Chaos Engineering by randomly terminating instances in production to ensure that engineers implement their services to be resilient to instance failures.

Chaos Monkey is designed to work on the Amazon Web Services (AWS) platform. It operates by randomly selecting a target from a specified group and terminating it. This random termination simulates potential real-world issues and allows developers to proactively identify and fix weaknesses in their systems. Chaos Monkey is fully integrated with Spinnaker, the continuous delivery platform that Netflix uses. It should work with any backend that Spinnaker supports (AWS, Google Compute Engine, Azure, Kubernetes, Cloud Foundry). It has been tested with AWS, GCE, and Kubernetes.

The primary advantage of Chaos Monkey is its maturity and wide adoption. Being one of the first tools in the field of Chaos Engineering, it has been thoroughly tested and refined. It's backed by Netflix, which gives it a strong support base.

However, Chaos Monkey's scope is primarily limited to AWS. While it can be a powerful tool for teams operating in an AWS environment, those using other platforms may find its functionality limited. Additionally, compared to some other Chaos Engineering tools, it may not offer as wide a range of chaos experiments.

2. Gremlin:

Gremlin is a Chaos Engineering platform developed by Gremlin Inc. It provides a fully hosted service that allows engineers to safely, securely, and easily simulate chaos to test how their systems handle failure scenarios.

Gremlin offers a wide range of attack vectors, including resource attacks (like CPU, memory, disk, and IO), state attacks (like shutdown and time travel), and network attacks (like latency, packet loss, and DNS). This makes it a comprehensive tool for a variety of chaos experiments.

One of the key advantages of Gremlin is its user-friendly interface, which makes it easy to design and run chaos experiments. It also provides strong support and detailed documentation, making it accessible for both beginners and experienced practitioners of Chaos Engineering.

However, Gremlin is not open-source, and its pricing can be a barrier for small teams or individual users. It's also a more complex tool, which may be more than some users need for simple chaos experiments.

3. Chaos Toolkit:

Chaos Toolkit is an open-source Chaos Engineering tool developed by ChaosIQ (now Reliably). It's designed to be a simple, easy-to-use, and extendable tool for running chaos experiments.

One of the key features of the Chaos Toolkit is its extendability. It provides a simple core that you can extend with plugins to support a wide range of platforms and technologies. This makes it a versatile tool that can be adapted to many different environments.

Chaos Toolkit also emphasizes simplicity and ease of use. It uses a declarative JSON or YAML format for defining chaos experiments, making it easy to understand and control what your experiments will do.

However, the Chaos Toolkit is less mature compared to some other Chaos Engineering tools, and it has a limited set of built-in attacks. It's also a more low-level tool, which means it may require more setup and configuration compared to a fully hosted service like Gremlin.

4. Litmus:

Litmus is an open-source Chaos Engineering tool developed by MayaData and the open-source community. It's a Kubernetes-native tool, meaning it's designed specifically to run chaos experiments in Kubernetes environments.

One of the key features of Litmus is its extensive chaos experiment library. It provides a wide range of pre-defined chaos experiments that you can use to test your Kubernetes applications, including pod failures, node failures, network latency, and more.

Litmus also emphasizes observability and SRE principles. It provides detailed metrics and logs for your chaos experiments, making it easy to understand the impact of the chaos and identify any issues.

However, because Litmus is Kubernetes-native, it's limited to Kubernetes environments. If you're not using Kubernetes, you may find its functionality limited.

5. PowerfulSeal:

PowerfulSeal is an open-source Chaos Engineering tool developed by Bloomberg. It's designed to inject failure into your Kubernetes clusters, helping you detect problems as early as possible.

One of the key features of PowerfulSeal is its robustness. It provides a wide range of chaos experiments, including killing pods, draining nodes, and introducing network latency. It also supports both automated and interactive modes, giving you flexibility in how you run your chaos experiments.

PowerfulSeal also emphasizes observability (with Prometheus or Datadog). It provides detailed logs and metrics for your chaos experiments, making it easy to understand the impact of the chaos and identify any issues.

However, PowerfulSeal is less user-friendly compared to some other Chaos Engineering tools. It requires more setup and configuration, and its command-line interface may be intimidating for beginners. It's also limited to Kubernetes environments.

6. Chaos Mesh:

Chaos Mesh is an open-source Chaos Engineering platform developed by PingCAP. It's designed to orchestrate chaos experiments in Kubernetes environments.

One of the key features of Chaos Mesh is its comprehensive range of fault types. It supports a wide variety of chaos experiments, including pod failures, network failures, I/O failures, and even JVM application failures. This makes it a versatile tool for testing the resilience of your Kubernetes applications.

Chaos Mesh also emphasizes ease of use. It provides a user-friendly dashboard for managing and monitoring your chaos experiments, making it accessible for both beginners and experienced practitioners of Chaos Engineering.

However, like Litmus and PowerfulSeal, Chaos Mesh is Kubernetes-native and is therefore limited to Kubernetes environments.

7. Pumba:

Pumba is a chaos testing and network emulation tool for Docker, developed by Alexei Ledenev. It's designed to introduce chaos and network latency to Docker containers to test their resilience and discover faults.

One of the key features of Pumba is its simplicity and lightweight nature. It operates directly on running Docker containers, making it easy to integrate into any Docker-based environment. It supports a variety of chaos experiments, including stopping, killing, and removing Docker containers, as well as introducing network latency, packet loss, and rate control.

However, Pumba is less mature compared to some other Chaos Engineering tools, and its scope is primarily limited to Docker environments. It's also a more low-level tool, which means it may require more setup and configuration compared to a fully hosted service.

8. ToxiProxy:

ToxiProxy is a framework for testing network conditions, developed by Shopify. It's designed to simulate different network conditions and failures, allowing you to test how your application handles them.

One of the key features of ToxiProxy is its focus on network conditions. It supports a variety of network failures, including latency, timeouts, and packet loss. This makes it a valuable tool for testing the resilience of your application to network issues.

ToxiProxy operates as a TCP proxy, introducing the specified network conditions between your application and any services it communicates with over the network. This makes it a versatile tool that can be used with any application that communicates over TCP.

However, ToxiProxy's scope is primarily limited to network conditions. If you need to test other types of failures, such as resource exhaustion or system failures, you may need to use it in conjunction with other Chaos Engineering tools.

Below are the high-level decision diagram & comparative table for all the discussed tools for implementing Chaos Engineering.

Conclusion:

Each of these tools has its strengths and weaknesses, and the best one for your team depends on your specific needs and environment. By understanding the capabilities of each tool, you can make an informed decision and embrace chaos to build more resilient systems.

Originally published at Wearecommunity-india-devtestsecops-community

"Are you tired of dealing with messy finally blocks just to ensure your resources get closed properly?"

"Have you ever found yourself tangled in a web of nested try-catch blocks, only to realize that your application is still prone to resource leaks?"

If so, you're not alone. Managing resources effectively is a common challenge for many Java programmers, including a surprising number of automation engineers I've interviewed. Despite being introduced in Java 7, the try-with-resources statement, a powerful feature that can greatly simplify resource management, remains underutilized in many areas, including test automation. Many engineers continue to use the traditional approach, missing out on the benefits of safer, more readable code.

In this blog post, we will delve into the try-with-resources statement, exploring how it works and how we can use it to improve the Java code. So, let's get started and say goodbye to those messy finally blocks!

Understanding Try-With-Resources

try-with-resources is a try statement that declares one or more resource declarations. An object that needs to be closed once the application has finished using it is called a resource. Files, network connections, and database connections are a few types of resources. The resources declared need to implement the Closeable or AutoCloseable interfaces.

An expression that uses try-with-resources declares the resource within the try statement. Upon completion of the try block, the resource is closed automatically. Compared to the conventional method, which required manually closing the resource in a finally block, this is a huge improvement.

Benefits:

The 'try-with-resources' statement has several benefits:

1. Simpler Code: We no longer need to write explicit code to close the resource in a finally block. This makes the code shorter and easier to read.

2. Better Resource Management: The try-with-resources statement ensures that the resource is closed promptly after the program is done using it. This can help prevent resource leaks that can cause the program to behave unpredictably.

3. Improved Exception Handling: If an exception is thrown both in the try block and when the resource is closed, the try-with-resources statement will suppress the exception thrown from the try block. This makes the exception-handling code more straightforward.

All the examples discussed here can be found onGitHub

Example:

Let us understand the usage with an example. To read a file using Scanner class below is the code snippet we write using the traditional try-catch-finally syntax.

    public void methodWithTryCatchFinally() {
        Scanner scanner = null;
        try {
            scanner = new Scanner(new File("input.txt"));
            while (scanner.hasNextLine()) {
                System.out.println(scanner.nextLine());
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } finally {
            if (scanner != null) {
                scanner.close();
            }
        }
    }

This method reads and prints the contents of a file named "input.txt". It uses a Scanner object to read the file line by line. The try block attempts to open the file and read its contents. If the file is not found, a FileNotFoundException is caught and its stack trace is printed. Regardless of whether an exception is thrown, the finally block ensures that the Scanner object is closed to prevent resource leaks.

Let us implement the same logic using try-with-resources syntax

    public void methodWithTryWithResources() {
        try (Scanner scanner = new Scanner(new File("input.txt"))) {
            while (scanner.hasNextLine()) {
                System.out.println(scanner.nextLine());
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }
    }

Here the try block, with the Scanner declaration within its parentheses is the try-with-resources section. Using this syntax automatically closes the resources declared within the parentheses when the try block is exited, either normally or via an exception. This ensures that the Scanner object is closed to prevent resource leaks, without needing an explicit finally block. If the file is not found, a FileNotFoundException is caught and its stack trace is printed.

Working with Multiple Files:

We can also use this syntax to declare and initialize multiple resources with try-with-resources

public void methodWithTryCatchFinally() {
        FileInputStream fis = null;
        FileOutputStream fos = null;
        try {
            fis = new FileInputStream("input.txt");
            fos = new FileOutputStream("output.txt");
            int data;
            while ((data = fis.read()) != -1) {
                fos.write(data);
            }
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            if (fis != null) {
                try {
                    fis.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
            if (fos != null) {
                try {
                    fos.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
    }

This example is also similar to the previous one, but now we work with 2 files in the try-with-resources section. The code reads data from a file named "input.txt" and writes it to another file named "output.txt". It uses FileInputStream to read the input file and FileOutputStream to write to the output file. The try block attempts to open both files, read data from the input file, and write it to the output file. If an IOException occurs during this process (for example, if one of the files does not exist or cannot be opened), the exception is caught and its stack trace is printed. The finally block ensures that both the FileInputStream and FileOutputStream are closed, regardless of whether an exception occurred. This is important to prevent resource leaks. If an IOException occurs while trying to close the files, it is also caught and its stack trace is printed.

Now, let us change it to a new syntax.

public void methodWithTryWithResources() {
        try (FileInputStream fis = new FileInputStream("input.txt");
             FileOutputStream fos = new FileOutputStream("output.txt")) {
            int data;
            while ((data = fis.read()) != -1) {
                fos.write(data);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

As you see the same logic has been written concisely using try-with-resources. It improves the readability of the program and reduces the complexity & redundant code for resource clean-up. The try-with-resources automatically closes the FileInputStream and FileOutputStream resources after use, preventing resource leaks. If an IOException occurs (like a file not found), it's caught and its stack trace is printed.

Working with Database Connections:

One more real-time example in test automation is, connecting to the DB and fetching the test data required for our test scripts. Here is how we write the code for this using the traditional approach.

    public void methodWithTryCatchFinally() {
        Connection conn = null;
        Statement stmt = null;
        try {
            conn = DriverManager.getConnection("jdbc:postgresql://localhost:5432/postgres",
                    "postgres", "password");
            stmt = conn.createStatement();
            ResultSet rs = stmt.executeQuery("SELECT * FROM users");
            while (rs.next()) {
                // process the row
            }
        } catch (SQLException e) {
            e.printStackTrace();
        } finally {
            if (stmt != null) {
                try {
                    stmt.close();
                } catch (SQLException e) {
                    e.printStackTrace();
                }
            }
            if (conn != null) {
                try {
                    conn.close();
                } catch (SQLException e) {
                    e.printStackTrace();
                }
            }
        }
    }

Here we are using native classes from java.sql JDBC classes to connect to a PostgreSQL database, execute a SQL query, and process the results. It uses a Connection object to establish a connection to the database and a Statement object to execute the query. The try block attempts to establish the connection, execute the query "SELECT * FROM users", and process each row of the result. If a SQLException occurs during this process (for example, if the database connection fails or the query is invalid), the exception is caught and its stack trace is printed. The finally block ensures that both the Statement and Connection objects are closed, regardless of whether an exception occurred. If a SQLException occurs while trying to close the objects, it is also caught and its stack trace is printed.

Let us convert this logic to use the new syntax.

    public void methodWithTryWithResources() {
        try (Connection conn = DriverManager.getConnection("jdbc:postgresql://localhost:5432/postgres",
                "postgres", "password");
             Statement stmt = conn.createStatement()) {
            ResultSet rs = stmt.executeQuery("SELECT * FROM users");
            while (rs.next()) {
                // process the row
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

Here we are doing the same logic but using a try-with-resources block to automatically manage the Connection and Statement resources. Thetry-with-resources block automatically closes the Connection and Statement objects after use, preventing resource leaks.

A try-with-resources block can still have the finally block, which will work in the similar way as with a traditional try block.

Conclusion

In this blog, we discussed how we can leverage try-with-resources instead of using trycatch and finally blocks for exception handling and writing efficient code. If you're not already using try-with-resources in your Java code, consider starting today!

As an automation engineer, testing APIs is a significant part of our role. While there are numerous tools available for this purpose, choosing the right one can significantly impact our testing efficiency. In this blog post, we'll explore several options, including native clients like HttpClient and HttpURLConnection, as well as REST Assured, Spring RestTemplate, Spring WebClient, and Apache HttpClient.

Let's explore a simple use case and add tests using all the options we have.

Consider our API URL https://jsonplaceholder.typicode.com/users/1 which returns the below JSON response.

So the test is to:

• Invoke the GET API using any client

• Get the response & validate status code is 200

• Validate some parts of the response, maybe name

Let's see how we can accomplish this with different approaches.

The complete code for this tutorial with all examples discussed can be found on GitHub.

1. HttpURLConnection

HttpURLConnection has been a part of the Java standard library since Java 1.1. It's a blocking API, meaning it will hold the thread until it gets the response. It only supports HTTP/1.1. Its API is also low-level, which means we would need to write more code to do the same tasks as with other options.

    @Test
    void testWithHttpURLConnection() throws IOException {
        // prepare request
        URL url = new URL(this.URL);
        HttpURLConnection connection = (HttpURLConnection) url.openConnection();
        connection.setRequestMethod("GET");

        // send request
        connection.connect();

        // validate response
        assertEquals(200, connection.getResponseCode());
        assertEquals("application/json; charset=utf-8", connection
                .getHeaderField("Content-Type"));

        BufferedReader reader = new BufferedReader(new InputStreamReader(connection.getInputStream()));
        String line;
        StringBuilder response = new StringBuilder();
        while ((line = reader.readLine()) != null) {
            response.append(line);
        }
        reader.close();

        assertTrue(response.toString().contains("Leanne Graham"));
        connection.disconnect();
    }

This JUnit test uses Java's native HttpURLConnection to send a GET request to the given URL and validates the response. It first creates a new URL object and opens a connection to it using HttpURLConnection. The request method is set to GET. Then, it sends the request by calling connect(). It validates the response by checking that the response code is 200, indicating success and that the Content-Type header is application/json; charset=utf-8. It then reads the response body using a BufferedReader and checks that the response body contains the string "Leanne Graham". If any of these checks fail, the test will fail. If all checks pass, the test will pass. The test may throw an IOException if there's a problem sending the request or receiving the response. After all operations, it disconnects the connection by calling disconnect().

2. HttpClient

Introduced in Java 11, HttpClient is a modern and flexible API that supports both HTTP/1.1 and HTTP/2. It provides both synchronous (blocking) and asynchronous (non-blocking) programming models. However, it's more of a low level and doesn't provide the same level of functionality for testing as some other options.

    @Test
    void testWithHttpClient() throws IOException, InterruptedException {
        // prepare request
        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder()
                .uri(URI.create(this.URL))
                .build();

        // send request
        HttpResponse<String> response = client.send(request,
                HttpResponse.BodyHandlers.ofString());

        // validate response
        assertEquals(200, response.statusCode());
        assertEquals("application/json; charset=utf-8", response.headers()
                .firstValue("Content-Type").get());
        assertTrue(response.body().contains("Leanne Graham"));
    }

This test uses Java's native HttpClient to send a GET request to a specified URL and validates the response. It first creates a new HttpClient instance and builds an HttpRequest for the specified URL. Then, it sends the HttpRequest using the HttpClient and receives the HttpResponse, specifying that the response body should be treated as a String. Then it validates the response as per our test scenario.

3. Apache HttpClient

Apache HttpClient is a robust, feature-rich, and flexible library that provides almost all the functionality needed to send HTTP requests and handle HTTP responses. It supports both blocking and non-blocking I/O models and provides full control over the HTTP protocol's details.

Make sure you're adding the appropriate Maven/Gradle dependency for Apache HttpClient in your project. For Maven, you can use:

    <dependency>
      <groupId>org.apache.httpcomponents.client5</groupId>
      <artifactId>httpclient5</artifactId>
      <version>5.3.1</version>
    </dependency>

    @Test
    void testWithApacheHttpClient() throws ProtocolException, IOException {
        // prepare request
        CloseableHttpClient httpClient = HttpClients.createDefault();
        HttpGet request = new HttpGet(this.URL);

        // send request
        CloseableHttpResponse response = httpClient.execute(request);

        // validate response
        assertEquals(200, response.getCode());
        assertEquals("application/json; charset=utf-8",
                response.getHeader("Content-Type").getValue());
        assertTrue(EntityUtils.toString(response.getEntity())
                .contains("Leanne Graham"));
        httpClient.close();
    }

This test uses Apache's CloseableHttpClient to send a GET request to a specified URL and validates the response. It first creates a new CloseableHttpClient and builds a HttpGet request for the specified URL. Then, it sends the HttpGet request using the CloseableHttpClient and receives the CloseableHttpResponse. It validates the response similar to the previous examples. After all operations, it closes httpClient to free up system resources.

4. Spring RestTemplate

RestTemplate is a synchronous HTTP client that was part of the Spring Framework. It provides a higher-level, more user-friendly API compared to HttpClient and HttpURLConnection. However, as of Spring 5, RestTemplate is in maintenance mode, and it's suggested to use the non-blocking WebClient instead.

Make sure you're adding the appropriate Maven/Gradle dependency for Spring Web in your project. For Maven, you can use:

    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId>
      <version>6.1.6</version>
    </dependency>

    @Test
    void testWithSpringRestTemplate() {
        // prepare and send request
        RestTemplate restTemplate = new RestTemplate();
        ResponseEntity<String> response = restTemplate.getForEntity(this.URL, String.class);

        // validate response
        assertEquals(200, response.getStatusCodeValue());
        assertEquals("application/json; charset=utf-8", response.getHeaders()
                .getFirst("Content-Type"));
        assertTrue(response.getBody().contains("Leanne Graham"));
    }

This test uses Spring's RestTemplate to send a GET request to a specified URL and validates the response. It first creates a new RestTemplate and sends a GET request to the specified URL, receiving the response as a ResponseEntity<String>. Then it validates the response as per our test scenario.

5. Spring WebClient

WebClient is a non-blocking, reactive web client introduced in Spring 5 as part of the WebFlux module. It's designed to work in a non-blocking way and is suitable for use in reactive applications where traditional blocking I/O operations are inefficient.

Make sure you're adding the appropriate Maven/Gradle dependency for Spring Webflux in your project. For Maven, you can use:

    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-webflux</artifactId>
      <version>6.1.6</version>
    </dependency>

    @Test
    void testWithSpringWebClient() {
        // prepare and send request
        WebClient webClient = WebClient.create();
        ClientResponse response = webClient.get()
                .uri(this.URL)
                .exchange()
                .block();

        // validate response
        assert response != null;
        assertEquals(HttpStatus.OK, response.statusCode());
        assertEquals("application/json;charset=utf-8",
                Objects.requireNonNull(response.headers().asHttpHeaders().getContentType())
                        .toString());
        assertTrue(Objects.requireNonNull(response.bodyToMono(String.class).block())
                .contains("Leanne Graham"));
    }

This test uses Spring's WebClient to send a GET request to a specified URL and retrieve the response. It creates an instance of WebClient, sends the request, and blocks until the response is received. It validates the response similar to the previous examples. The Objects.requireNonNull() calls are used to ensure that the getContentType() and bodyToMono(String.class).block() methods do not return null. If they do, a NullPointerException will be thrown.

6. REST Assured

REST Assured is an open-source Java library that simplifies the testing and validation of REST APIs. It provides a high-level, fluent API for sending HTTP requests and validating responses, making it an ideal tool for testing in a behavior-driven development (BDD) style. It is built on top of Apache HTTP Client for handling HTTP requests and responses and Groovy for its syntax and language features. It also uses other libraries such as GSON and Jackson for JSON, and JAXB for XML.

Make sure you're adding the appropriate Maven/Gradle dependency for REST Assured in your project. For Maven, you can use:

    <dependency>
      <groupId>io.rest-assured</groupId>
      <artifactId>rest-assured</artifactId>
      <version>5.4.0</version>
      <scope>test</scope>
    </dependency>

    @Test
    void testWithRESTAssured() {
        given().
                baseUri(this.URL).       // prepare request
        when()
                .get().                  // send request
        then()
                .statusCode(200).and()   // validate response
                .body(containsString("Leanne Graham")).and()
                .header("Content-Type", "application/json; charset=utf-8");
    }

This test uses REST Assured to send a GET request to a specified URL and validate the response. The baseUri(this.URL) method sets the base URL for the request. The get() method sends the GET request. The statusCode(200) assertion checks that the status code of the response is 200, indicating success. The and() methods are used for readability and do not affect the execution of the test.

As we see with our examples, writing API tests & adding assertions with REST Assured is very easy. It stands out for its ease of use, powerful validation features, support for various types of authentication, and flexibility. It's built on top of the Apache HttpClient, which means we can customize it to suit our needs. We can add filters, define the request and response specifications, and more. Using REST Assured, we can write efficient tests with very few lines of readable code.

REST Assured offers several benefits for testing RESTful APIs:

1. BDD Format: REST Assured supports Behavior Driven Development (BDD) format, making it easier to write, read, and understand tests. This also facilitates communication between developers, testers, and non-technical stakeholders.

2. DSL: REST Assured provides a Domain Specific Language (DSL) for writing tests, which simplifies the process of writing complex HTTP requests.

3. Specification: It allows you to define detailed specifications for the API, which can be used to generate detailed reports and documentation.

4. Schema Validation: REST Assured supports schema validation for both JSON and XML, ensuring that the API responses match the expected structure.

5. Ease of Use: REST Assured is designed to be simple and intuitive, making it easy for beginners to get started with API testing.

6. Integration: It integrates seamlessly with existing Java-based testing ecosystems, including JUnit and TestNG.

7. Flexibility: REST Assured supports a variety of HTTP methods, including GET, POST, PUT, DELETE, OPTIONS, PATCH, and HEAD, and can handle any type of MIME type, providing flexibility in testing different types of APIs.

8. Authentication Support: REST Assured supports various types of authentication, such as Basic, Digest, Form, and OAuth, making it easier to test APIs that require user authentication.

9. Detailed Logging: REST Assured provides detailed logging capabilities, which can be very helpful for debugging and understanding the flow of requests and responses.

10. Built-in Support for Hamcrest Matchers: REST Assured includes built-in support for Hamcrest matchers, which allows for more readable and flexible assertions. This enhances the descriptiveness of our tests, making them easier to read and maintain.

Overall, REST Assured provides a comprehensive and user-friendly framework for testing RESTful APIs, making it a popular choice among developers and testers.

Here's a comparison table for all the mentioned solutions:

Conclusion

While native clients like HttpClient and HttpURLConnection, as well as libraries like Spring RestTemplate, Spring WebClient, and Apache HttpClient have their specific uses, REST Assured is a superior choice for test automation engineers looking to efficiently test REST APIs. Its high-level, fluent API, powerful validation features, and support for various types of authentication make it a versatile and efficient tool for API test automation. So, if you're an automation engineer looking to streamline your API testing, give REST Assured a try!

In today's rapidly evolving digital landscape, where systems are becoming increasingly complex and interconnected, ensuring the reliability and resilience of software applications is more critical than ever. In this quest for robustness, a new discipline called "Chaos Engineering" has emerged. Chaos Engineering is not about causing chaos, but rather a proactive approach to testing and strengthening systems by intentionally injecting controlled chaos into them. By embracing chaos, organizations can uncover vulnerabilities, improve their system's reliability, and ultimately deliver better experiences to their users.

The definition of ‘Chaos Engineering’ has been defined by various groups & organizations:

• Chaos Engineering is the discipline of experimenting on a system to build confidence in the system’s capability to withstand turbulent conditions in production. - principlesofchaos

• Chaos Engineering goes beyond traditional (failure) testing in that it's not only about verifying assumptions. It helps us explore the unpredictable things that could happen, and discover new properties of our inherently chaotic systems. - Gremlin

• Chaos engineering is the science behind intentionally injecting failure into systems to gauge resiliency – Harness

Understanding Chaos Engineering

Chaos Engineering is rooted in the idea that to build resilient systems, it is essential to actively test their behavior under adverse conditions. The approach draws inspiration from real-world experiences where systems fail due to unexpected circumstances, and aims to simulate those scenarios in a controlled environment.

Chaos Engineering is like a firefighter running practice drills. By intentionally setting controlled fires, the firefighters can understand how quickly it might spread, how effectively they can eliminate it, and what tactics work best under pressure. Similarly, Chaos Engineering believes in creating troublesome situations for a system to understand how it reacts. Just like the real world, where unexpected things can go wrong, these simulated conditions help find out the weak points in a system. By learning from these experiments, the organization can work on strengthening these weak areas, making the system more resilient and better equipped to deal with actual problems if they arise.

¹ Image generated with Dall-E3

Similarly, Chaos Engineering tests systems under less-than-ideal conditions on purpose. It recreates situations where things could go wrong due to unanticipated circumstances. With this, organizations can see the weak points in their systems, and work to make them stronger and better equipped to handle such situations effectively in the future. The controlled environment ensures that while these tests are going on, the normal functioning of the system is not provoked into a real chaotic situation.

Chaos Engineering Principles

Chaos Engineering is guided by a set of core principles that drive its practice. Let's explore them briefly.

• Start with establishing a steady state: This refers to defining normal behavior for your system to understand its expected outcomes better.

• Hypothesize about what will happen: Chaos experiments begin with a clear hypothesis about how the system will behave under certain chaotic conditions. This hypothesis serves as a guide to identify potential vulnerabilities and expected outcomes.

• Introduce variables that reflect real-world events: Chaos experiments should mirror factors that could likely occur within your production environment.

• Attempt to disprove the hypothesis: By introducing controlled disruptions, you can test whether the system works as expected. If not, you will learn about a vulnerability.

Other principles include:

• Define measurable outcomes: Chaos experiments should have measurable objectives and success criteria. This ensures that the results can be evaluated objectively and the impact of chaos can be quantified.

• Focus on steady-state behavior: Chaos experiments primarily aim to test a system's behavior under normal operating conditions. The goal is to uncover weaknesses that might not surface during regular testing or in controlled environments.

• Apply blast radius limits: To minimize the potential impact of chaos experiments, it is crucial to define the scope and boundaries. By limiting the blast radius, organizations can control the impact on the system and mitigate potential risks.

• Automate where possible: Chaos experiments should be automated to enable repeatable, controlled chaos. Automation reduces human error, ensures consistency, and allows for scaling the chaos engineering practice.

Source: Apexon Whitepaper on Chaos Engineering

Benefits of Chaos Engineering

Implementing Chaos Engineering as a proactive practice brings several benefits to organizations.

• Improved system resilience: Early vulnerability and weak point identification allow companies to make the necessary changes to strengthen their systems. By identifying these weak spots before they become operational problems, chaos engineering contributes to the overall resilience of the system.

• Reduced downtime and increased availability: Organizations can identify possible failure situations and take the necessary steps to prevent or recover from them by using chaos experiments. Organizations may reduce downtime and guarantee high availability for their clients by proactively identifying these issues.

• Enhanced customer experience: Chaos Engineering contributes to more streamlined and dependable end-user experiences by proactively testing and fixing system flaws. It assists businesses in identifying any problems and acting upon them before they negatively affect the consumer experience.

• Cultural shift towards resilience: Through a cultural shift, Chaos Engineering assists organizations in making resilience a priority. It educates groups to embrace difficulties and see flaws as chances for improvement. By promoting a culture of ongoing learning and development, this strategy creates systems that are more reliable and strong.

Let's use an eCommerce website as an example for demonstrating the Chaos Engineering principles.

1. Start with Establishing a Steady State: The normal operations of this eCommerce site might involve users browsing items, adding them to a cart, checking out, and making a payment. The performance metrics of these operations like load time, server response time, success rate of transactions, etc., in normal conditions, are recorded.

2. Hypothesize About What Will Happen: Let's hypothesize that if the payment gateway service were to fail, users would still be able to browse items and add them to their carts, but wouldn't be able to complete transactions.

3. Introduce Variables Reflecting Real-World Events: You simulate a real-world event - in this case, the failure of the payment gateway. This could be replicated by intentionally disabling the payment gateway service.

4. Automate Experiments and Try to Disprove the Hypothesis: You run the test automatically using chaos engineering tools during peak business hours when the web traffic is high. Observe what happens: Can users still browse and add items to their carts? Does the checkout process fail gracefully, with users receiving an appropriate error message?

5. Minimize Blast Radius: Instead of running this test in the live environment affecting all users, you first run it in a controlled environment, like a clone of your production environment, affecting a limited number of users. This ensures that in case the test reveals serious issues, your entire user base is not affected.

By following these principles, chaos engineering allows businesses to proactively identify and fix potential system weaknesses, ensuring that their services run smoothly, and customer experience is not disrupted, even in the event of unexpected system failures.

Real-time incidents

Here are a few notable incidents where a lack of chaos engineering has played a part in service disruption or application outage:

1. GitHub (October 21, 2018): GitHub went down for 24 hours due to data storage system failure. The direct cause was a network partition, which led to inconsistency across their data storage system. Chaos engineering practices could have helped detect such a vulnerability beforehand.

   https://github.blog/2018-10-30-oct21-post-incident-analysis/

2. Amazon (September 20, 2015) – Dynamo DB availability issue: Amazon's DynamoDB faced an availability issue in one of its regional zones, leading to the failure of more than 20 Amazon Web Services that depended on DynamoDB in that particular region. As a result, several websites, including Netflix, experienced downtime for a few hours. However, Netflix's outage was less severe compared to other sites, thanks to their foresight in creating and utilizing a chaos engineering tool known as Chaos Kong, which helped them prepare for such situations.

• https://netflixtechblog.com/chaos-engineering-upgraded-878d341f15fa

• https://aws.amazon.com/message/5467D2/

3. Amazon AWS (February 28, 2017) – S3 service outage: A major outage in Amazon's S3 web service resulted in disruption for many online services. The outage was reportedly due to a command that was incorrectly entered during a routine debugging. Chaos engineering could have helped develop safeguards against such human errors.

• https://www.gremlin.com/blog/the-2017-amazon-s-3-outage

• https://aws.amazon.com/message/41926/

Metrics to measure

Below are some metrics that can help measure the effectiveness of chaos engineering efforts and guide future experiments.

Tools and Technologies

Chaos Engineering has gained significant popularity as a proactive approach to building resilient systems. To effectively practice chaos engineering, various tools, and technologies have emerged to assist in creating controlled chaos experiments. Some of the most used tools are:

• Chaos Monkey: Developed by Netflix

• Gremlin: Developed by Gremlin Inc

• Chaos Toolkit: An open-source project developed by ChaosIQ (now Reliably)

• Litmus: Developed by MayaData & the open-source community

• PowerfulSeal: Developed by Bloomberg

• Chaos Mesh: Developed by PingCAP & incubating project at CNCF

• Pumba: Developed by Alexei Ledenev

• ToxiProxy: Developed by Shopify

Conclusion

Considering the current state of technology, chaos engineering is an essential topic that aids companies in creating robust systems despite growing complexity. By embracing chaos and conducting controlled experiments, organizations can find vulnerabilities, build resilience, and enhance user experience. As long as technology advances, businesses will be able to test and enhance their systems beforehand and make sure they can function even in the face of disorder by utilizing chaos engineering as a potent weapon.

Chaos engineering tools and technologies have significantly contributed to the adoption and practice of chaos engineering. Each tool mentioned above offers unique advantages and disadvantages, and the choice of tool depends on factors such as the organization’s specific requirements, existing infrastructure, and budget constraints. Regardless of the tool chosen, the adoption of chaos engineering practices can help organizations build more resilient systems, proactively identify weaknesses, and ultimately enhance the overall reliability and user experience of their applications.

Originally published at Wearecommunity-india-devtestsecops-community

Appendix:

1. Prompt used -> Visualize an intense scene where a female firefighter is in full gear, courageously running practice drills amidst roaring flames. The controlled fire is blazing intensely, illuminating the dusk sky. You also see a male firefighter in the background, coordinating operations over the radio. Include multiple firefighting vehicles like fire engines and water tenders, ready with their lights flashing, adding to the drama of the scenario. Capture the dedication of these professionals, their teamwork, and the adrenaline-filled atmosphere.

2. References:

   • https://principlesofchaos.org/

   • https://www.gremlin.com/chaos-engineering

   • https://www.harness.io/blog/chaos-engineering

   • https://www.gremlin.com/community/tutorials/chaos-engineering-monitoring-metrics-guide

https://leetcode.com/problems/reverse-words-in-a-string/

String input = "Hello World!";
String output = "World! Hello"

Solution-1

import org.testng.annotations.Test;

import java.util.Arrays;

import static org.assertj.core.api.Assertions.assertThat;

public class Solution1 {

    String input1 = "Hello World!";             // "World! Hello"
    String input2 = " Hello World! ";           // "World! Hello"
    String input3 = "Hello  World its  me ";    // "me its World Hello"

    public String reverseWordsS1(String sentence) {
        String[] words = sentence.split(" ");
        StringBuilder reversedString = new StringBuilder();

        // to remove the empty strings in the array - corner case
        String[] modifiedWordsArray = Arrays.stream(words)
                                            .filter(s -> !s.isEmpty())
                                            .toArray(String[]::new);

        for (int i = modifiedWordsArray.length - 1; i >= 0; i--) {
            reversedString.append(modifiedWordsArray[i]).append(' ');
        }
        return reversedString.toString().trim();
    }

    @Test
    public void testLogic() {
        assertThat(this.reverseWordsS1(input1)).isEqualTo("World! Hello");
        assertThat(this.reverseWordsS1(input2)).isEqualTo("World! Hello");
        assertThat(this.reverseWordsS1(input3)).isEqualTo("me its World Hello");
        assertThat(this.reverseWordsS1(input4)).isEqualTo("Hello");
    }
}

In this code, the reverseWords function takes a sentence as input, splits the sentence into an array of words, and then appends the words in reverse order to a StringBuilder object. Finally, it returns the reversed string. If any any case, there are empty Strings in the given array, we need to filter them as well.

If you run this code with "Hello World!" as input, it will print: "World! Hello".

Solution-2:

Another approach is to use a stack. Stack follows a last-in, first-out (LIFO) principle which can be used to reverse the words in a sentence.

import org.testng.annotations.Test;

import java.util.Arrays;
import java.util.Stack;

import static org.assertj.core.api.Assertions.assertThat;

public class Solution2 {

    public String reverseWordsS2(String sentence) {
        String[] words = sentence.split(" ");
        Stack<String> stack = new Stack<>();

        String[] modifiedWordsArray = Arrays.stream(words)
                                        .filter(s -> !s.isEmpty())
                                        .toArray(String[]::new);

        for (String word: modifiedWordsArray) {
            stack.push(word);
        }

        StringBuilder reversedString = new StringBuilder();

        while (!stack.isEmpty()) {
            reversedString.append(stack.pop()).append(' ');
        }
        return reversedString.toString().trim();
    }
}

In this version of the code, it splits the sentence into words and then pushes each word onto a stack. It then pops each word off the stack, which results in the words being in reverse order, and appends them to a StringBuilder object. Finally, it returns the reversed string.

Solution-3:

We can also use Java 8's Stream API to reverse the words in a sentence.

import java.util.Arrays;
import java.util.stream.Collectors;

public class Solution3 {
    public String reverseWordsS3(String sentence) {
        String[] words = sentence.split(" ");
        String[] modifiedWordsArray = Arrays.stream(words)
                                        .filter(s -> !s.isEmpty())
                                        .toArray(String[]::new);

        return Arrays.stream(modifiedWordsArray)
                                .reduce((firstWord, secondWord) -> secondWord + " " + firstWord)
                                .orElse(sentence);
    }
}

In this version of the code, it uses the split method to divide the sentence into an array of words. This Arrays.stream creates a Stream of this array. The reduce operation then combines these words in reverse order. The orElse method returns the original sentence if it consists of only one word without space. Finally, the reversed sentence is returned.

Solution-4:

Another approach using the Deque interface in Java. A Deque (short for Double Ended Queue) is a data structure that allows you to insert and remove elements from both ends. This makes it very suitable for problems involving reversal or rotation.

import java.util.ArrayDeque;
import java.util.Deque;
import java.util.List;
import java.util.ArrayList;

public class Solution4 {
   public String reverseStringS4(String sentence) {
        String[] words = sentence.split(" ");

        // to remove the empty strings in the array - another approach
        List<String> list = new ArrayList<>(Arrays.asList(words));
        list.removeIf(String::isEmpty);

        String[] modifiedArray = list.toArray(new String[0]);
        Deque<String> stack = new ArrayDeque<>();

        for (String word : modifiedArray) {
            stack.push(word);
        }

        StringBuilder reversedSentence = new StringBuilder();

        while (!stack.isEmpty()) {
            reversedSentence.append(stack.pop());
            if (!stack.isEmpty()) {
                reversedSentence.append(" ");
            }
        }
        return reversedSentence.toString();
    }
}

In this code, the reverseWords function splits the sentence into an array of words and pushes each word onto a stack (implemented as an ArrayDeque). Then it pops each word off the stack (which results in the words being in reverse order) and appends them to a StringBuilder. If the stack is not empty after popping a word, it adds a space to the StringBuilder. Finally, the function returns the reversed sentence.

Comparative table:

Notes:

• In the time complexity, 'n' is the length of the input string.

• All of the mentioned approaches have the same time complexity (O(n)) because they all traverse the string once.

• All the other approaches use additional data structures and thus, have a linear space complexity (O(n)). Also, space complexity includes both fixed and variable space.

• GitHub

The below materials helped with my exam preparation:

1. Microsoft Official Documentation - good material with all basics & hands-on labs on Azure. A must-read for everyone.

2. AI-900 full course by ExamPro - available on YouTube - 4hrs video - some of the concepts are outdated, due to service name changes in Azure. But gives a detailed outlook in a short time.

3. Cheat-sheet from Whizcards for a quick refresher before the exam - some of the concepts are outdated, due to service name changes in Azure.

Practice tests:

1. Official practice tests from MS ~200+ questions (tried multiple times, with some repeated questions though)

2. Practice questions from ExamTopics ~120 questions with a free account - some of these appeared in the actual exam!

Exam experience:

1. I chose to attempt from a test center near where I live.

2. There are a total of 42 questions that need to be answered in 45 minutes. We need to manage time effectively. Got different question types - selecting a single answer, multiple answers, drag-drop, etc.

3. The first 5-6 questions were very tricky, with lengthy descriptions & images - which will waste our time. Though there are very simple questions at the end of the exam!

4. Minimum 3-4 questions from Responsible AI in Azure - very important topic.

5. Some questions around - OpenAI/AzureOpenAI/ChatGPT/Github Co-pilot/LLM models from OpenAI.

6. As usual, we can mark any question for review and check later - the best option is to cover all the questions at least once in the given time frame.

7. Given my preparation, I felt the test was of medium complexity.

Here is my certificate

All the best with your preparation!

Let's take an example API call for this. We will be using the below free fake API site to demonstrate this.

JSON Placeholder Fake API

• Open the above link in the Chrome browser

• Open developer tools either via navigating to Chrome Options > More Tools > Developer Tools OR using the shortcut CTRL + SHIFT + I / CMD + OPTION + I (Mac)

• Click on the Run Script button to invoke the below sample API and see the response in the developer tools under the Network tab

  

• Take a look at the request details like - Request URL, headers, cookies, etc.

• Select the request and right-click to see the options menu, then choose Copy > Copy as cURL

Curl (short for "Client URL") is a command-line tool that enables data transfer over various network protocols.

If the chrome is opened in windows, there will be 2 options for cURL - one for BASH and another for CMD

• Now the entire request details are added to the clipboard, something like this

curl 'https://jsonplaceholder.typicode.com/todos/1' \
  -H 'authority: jsonplaceholder.typicode.com' \
  -H 'accept: */*' \
  -H 'accept-language: en-US,en;q=0.9,te;q=0.8' \
  -H 'cookie: _ga=GA1.1.63507224.1695719458; ajs_anonymous_id=c601a09a-3cc6-4b84-a482-f58a353eea86; _ga_E3C3GCQVBN=GS1.1.1695719458.1.1.1695720002.0.0.0' \
  -H 'if-none-match: W/"53-hfEnumeNh6YirfjyjaujcOPPT+s"' \
  -H 'referer: https://jsonplaceholder.typicode.com/' \
  -H 'sec-ch-ua: "Chromium";v="116", "Not)A;Brand";v="24", "Google Chrome";v="116"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36' \
  --compressed

Use in terminal

We can simply paste the copied content and hit the request in the terminal. As we see, the correct response is being shown.

Use in Postman

Postman has an import option to load the API requests. Let's use the below option to import the request and check the response.

• Open Postman, navigate to File > Import > Raw text option paste the text that we copied in the previous step, and click Continue and then Import

• Once the request is sent to the server, we see the same response.

We may ignore the response codes for this example - as the server responds with 304 in the browser due to internal redirection logic whereas it gives 200 in the postman for the same call.

Using the copied cURL command in Postman, we can effortlessly edit it according to our needs and begin utilizing the APIs immediately. Other browsers - Firefox, Edge, Safari, etc. also have similar features to get this info from the developer tools making developers' lives easy.

Thank you for reading!

With the help of well-designed Continuous Integration systems in place, teams can build quality software by developing and verifying it in smaller increments. Continuous Integration (CI) is the process of pushing small sets of code changes frequently to the common integration branch rather than merging all the changes at once. This avoids big-bang integration before a product release. Test automation and Continuous Integration are an integral part of the software development life cycle. As the benefits of following DevOps methodology in a development team becomes significant, teams have started using different tools and libraries like Travis CI with Docker to accomplish this activity.

In this blog, we will discuss the role of Travis CI in Selenium test automation and dive deep into using Travis CI with Docker. We will also look at some effective Travis CI and Docker examples. We would also integrate and automate Selenium tests suites with Travis CI on the LambdaTest cloud grid.

Without further ado, Let’s build a CI/CD pipeline with Travis CI, Docker, and LambdaTest.

Overview Of Travis CI

Travis CI is a cloud-based service available for teams for building and testing applications. As a continuous integration platform, Travis CI supports the development process by automatically building and testing the code changes, providing immediate feedback if the change is successful. It can also help us automate other steps in the software development cycle, such as managing the deployments and notifications.

Travis CI can build and test projects on the cloud platform hosted on code repositories like GitHub. We could also use other best CI/CD tools such as Bitbucket, GitLab, and Assembla, but some of them are still in the beta phase. When we run a build, Travis CI clones the repository into a brand-new virtual environment and performs a series of steps to build and test the code.

When a build is triggered, Travis CI clones the GitHub repository into a brand-new virtual environment and performs a series of tasks to build and test the code. If any of those jobs fails, the build is considered broken; else, the build is successful. On the success of the build, Travis CI will deploy the code to a web server or an application host.

In case you are eager to learn about the Travis CI/CD pipeline, please refer to our detailed blog that deep dives into how to build your first CI/CD pipeline with Travis CI.

.travis.yml Configuration

Builds on Travis CI are configured mostly through the build configuration defined in the file .travis.yml in the code repository. It allows the configuration to be version-controlled and flexible. Once the application code is completed, we need to add the .travis.yml file to the repository.

It contains the instructions on what to build and how exactly to test the application. Travis CI performs all the steps configured in this YAML file.

Some of the commonly used terms associated with Travis CI are:

• Job – Job is an automated process that clones the code repository into a brand-new virtual environment and performs a set of actions such as compiling the code, running tests, deploying the artifact, etc.

• Phase – Job is a collection of different phases. Sequential steps, aka phases, collectively create a job in Travis CI. For example, install phase, script phase, before_install phase, etc.

• Build – Build refers to a group of jobs that are running in a sequence. For example, a build can have two jobs defined in it. Each job tests the project with a different version of the programming language. The build is finished only when all of its jobs have completed execution.

• Stage – Stage refers to the group of jobs that run in parallel.

  Features Of Travis CI

  Some of the salient features that Travis CI provides as a CI/CD platform are given below:

  1. Free cloud-based hosting

  2. Automatic integration with GitHub

  3. Safelisting or Blocklisting branches

  4. Pre-installed tools and libraries for build and test

  5. Provision to add build configuration via a shell script

  6. Caching the dependencies

  7. Building Pull-Requests

  8. Support for multiple programming languages.

  9. Build Configuration Validation.

  10. Easily set up CRON jobs.

  In case you want to deep dive into how Jenkins (the preferred open-source CI/CD tool) stacks up against Travis CI, please refer to our blog Travis CI Vs. Jenkins to make an informed decision.

  Overview Of Docker

  According to the Stack Overflow 2021 Developer survey, Docker is one of the most used containerization platforms to develop, ship, and run applications.

  

  Source

  Docker enables us to separate applications from the infrastructure so that the application software can be delivered quickly. In short, Virtual Machines(VM) virtualizes the hardware, whereas Docker virtualizes the Operating System(OS).

  In a Virtual Machine – multiple operating systems are run on a single host machine using the virtualization technology known as Hypervisor. Since the full OS needs to be loaded, there may be a delay while booting up the machines; also, there is an overhead of installing and maintaining the operating systems. Whereas in Docker, the host operating system itself is leveraged for virtualization.

  Docker daemon, installed on the host machine, manages all the heavy lifting tasks like listening to the API requests, managing docker objects (images, containers, and volumes), etc. In case you are looking to leverage Docker with Selenium, do check out our detailed blog that outlines how to run Selenium tests in Docker.

• Some of the useful concepts Docker leverages from the Linux world are as follows:

• Namespaces – Docker uses a technology called namespaces to provide the isolated workspace called container. For each container, Docker creates a set of namespaces when we launch it. Some namespaces in Linux are pid, net, ipc, mnt, and uts.

• Control Groups – Docker Engine on Linux also uses another technology known as control groups (cgroups). A cgroup restricts an application to a limited set of resources.

• Union file systems – Union file systems, or UnionFS, are lightweight and fast file systems that work by creating layers. Docker Engine makes use of UnionFS to provide container building blocks.

• Container Format – Docker Engine combines the namespaces, control groups, and UnionFS into a container format wrapper. The default container format is libcontainer.

  Basics Of Docker

  Docker uses a client-server architecture at its core. Some of the common objects and terminology used in Docker are explained below.

  • Image – An image is a read-only template with all the required instructions to create a Docker container. The image is a collection of files and metadata. These files collectively form the root filesystem for the container. Typically images are made up of layers which are stacked on top of each other. And these images can share layers to optimize disk usage, memory usage, and transfer times.

  • Container – Container is the runnable instance of an image. Containers have their lifecycle to create, start, stop, delete, and move using the Docker client API commands. Containers are by default isolated from other containers and the host machine. Basically, the container is defined by the image it is created from. If required, we need to give specific configuration or environment variables before starting it.

  • Engine – Docker Engine is a client-server application that includes the following major components.

    • A server is a form of long-running application known as a daemon process (i.e. the Dockerd command).

    • A REST API defines interfaces that applications can use to communicate with the daemon and instruct it on what needs to be done.

    • A client for the command-line interface (CLI) (i.e. the Docker command).

  • Registry – Registry is a place where all the Docker images are stored and distributed. Docker hub manages all the openly available docker images.

  • Network – Docker uses a networking subsystem on the configurable host OS, using different drivers. These drivers provide the core networking functionality.

    • Bridge

    • Host

    • Overlay

    • Macvlan

    • none

  • Volume – Since Docker containers are ephemeral by default, we need a provision to store the data between 2 different containers. Docker volumes provide this functionality where the data is persisted across containers.

  • Dockerfile – It is a flat-file with instructions on how to create an image and run it.

  • Docker-compose – Docker compose is a utility tool for defining and running multi-container docker applications. Here we use a YAML file to configure the services required for the application. By using a single command, we can start all the services and also establish dependencies between them.

How to Integrate Travis CI with Selenium using Docker

Using Docker Images

Now that we have understood the fundamentals of Travis CI and Docker let us start using them together to run some UI tests with Selenium WebDriver.

The first step is to define a test scenario for our Travis CI and Docker Example. Here is the Selenium test scenario:

1. Open a specific browser – Chrome, Firefox, or Edge

2. Navigate to the sample application

3. Verify headers on the page

4. Select the first two checkboxes and see if they are selected

5. Clear the textbox – Want to add more and enter some text into it and click on Add

6. Check if the new item is added to the list and verify its text

Here is the code that we need to write using Selenium WebDriver agnostic of any browser. First, we use the BrowserFactory to instantiate the browser based on the input and pass it on to our tests.

We are using TestNG and adding appropriate annotations for our tests. We also configured the testng.xml file to include what tests to run.

And finally, we use the below Maven command to trigger the tests. In case you are relatively new to Maven, do check out our detailed blog that will help you getting started with Maven for Selenium Automation.

The entire code for this project is available on the GitHub repository.

Since our goal is to configure and run the Selenium tests using Travis CI and Docker, you should check the following prerequisites:

1. Active GitHub account, with the code repository available in GitHub.

2. Active TravisCI account and the required permissions to access the repository from GitHub.

Once all these prerequisites are met, let’s take a quick look at the travis.yml file configured in the project.

As we learned earlier, travis.yml is the configuration file that we use to instruct the Travis CI cloud server on what actions to perform for the given project.

Let’s understand all these details one by one.

dist: When a new job is started in Travis CI, it spins up a new virtual environment in the cloud infrastructure. Each build is run in the pre-configured virtualization environments. Then, using the dist key, we specify the infrastructure needed to be spun up by the server. Some of the available values for dist in the Linux environment are trusty, precise, bionic, etc.

language: Language key is used to specify the language support needed during the build process. We can choose the language key appropriately from the list of available values. Some examples include Java, Ruby, Go, etc.

jdk: The key JDK is used while the language key is selected as Java. We basically give the version of the JDK that needs to be used while building the project. In our case, it should be oraclejdk8 as we are using Java 1.8 version.

script: Script key is used to run the actual build command or script specific to the selected language or environment. In the example, we use mvn commands as we have created a maven-based project for the example.

before_script: It is used to run any commands before running the actual script commands. Before running the Maven command in the script phase, we need to ensure the Docker environment is set up successfully.

cache: This key is used to cache the content that doesn’t change frequently, and running this can help speed up the build process. Cache has many supported keys available for different caching strategies. Some of them are directories, npm, cache, etc.

directories: This is a caching strategy used for caching the directories based on the given string path.

We can also use the build configure explorer from Travis CI and check how the Travis CI system reads and understands the configuration. This is helpful in validating the configuration, adding the correct keys, and updating as per the latest specifications.

Once the prerequisites mentioned above are met, we can start with our build-in Travis CI with Docker. There are various ways in which we can start the builds.

1. Commit the code and push to Github; the default hook will trigger a new build on the server.

2. Manually trigger a build from the dashboard views.

3. Trigger with the Travis CI API.

Here is the default dashboard view of my user in Travis CI. As we can see, I have activated only two projects from GitHub.

From any of the options described above, Travis CI will start performing the below actions when a build is triggered:

1. Reads the configuration defined in travis.yml

2. Adds the build to the job queue

3. Start creating the brand new virtual environment to execute the steps mentioned in the travis.yml file

In the View config tab, we can also see the build configuration as read by Travis CI. Since we haven’t specified any os value in the travis.yml file, it takes the default value as Linux and proceeds with the build set-up.

Once the build is completed, we could see the image banner which indicates that the build has passed successfully. It also gives us other information such as branch information, time taken for execution, latest commit message, operating system information, build environment, etc.

Let’s navigate to the Job log section and understand what Travis CI and Docker have performed for our build.

In the Job log section, we can see the complete log information for the current job. As seen below, Travis CI has spun up the below worker for our build. It has created a new instance in the Google Cloud Platform, and the start-up time is around 6.33 seconds.

Travis CI will dynamically decide which platform (like GCP Compute Engine or AWS EC2 machines) to choose for the instance. If an enterprise version is used, we could also configure our infrastructure to be used by Travis CI.

In the Build system information from the logs, we could identify the build language used, the distribution of the OS, Kernel version, etc. For each operating system, Travis CI has a set of default tools defined already. Travis CI will install and configure all the required services required for the build. In this case, Git is installed.

Also, the Docker client and server will be installed by default. We can verify the version used by these components in the below screenshot:

Since our build config uses Java JDK, Travis CI will configure the JDK as specified in the travis.yml file and update the JAVA_HOME path variable as appropriate.

Next, it clones the latest code from the specific branch(master in our example) and updates the current directory. It also reads the environment variables if defined and updates the set-up as needed. Finally, it also checks if there is any build-cache defined for the project. We will discuss more about build cache in the later section.

Before pointing our tests to a remote server, we should have a browser configured on a specific port and listen for the incoming requests. From our example, we have configured the RemoteWebDriver as below for launching our tests in Chrome.

If you remember the travis.yml file in our project, we have a before_script stage defined, and we have already added the below two commands.

Let’s understand the commands that we have used.

The first one is the Docker run command that starts the Selenium Firefox container on port 4444.

docker: Docker is the base command for its CLI

run: Runs the commands in a new container

-d: Command option for Docker run to run the container in the background

-p: Command option for Docker run to publish a container’s port to the host port. Here we are mapping the 4444 port of the container to the 4444 port in the host. The format is host port: container port

-v: Command option for Docker run to bind mount a volume. Here we are using the shared memory /dev/shm in the container and mapping it to the shared memory /dev/shm of the host.

Next is the image that we are using to run the docker command. Here we are using the Selenium Firefox standalone image with tag 4.0.0-rc-1-prerelease-20210618. More information about the latest versions available can be found from the official Selenium Github repository and the Docker hub public registry.

Using the below command, Travis CI pulls the specified Selenium Firefox image from the Docker registry and starts creating a new container with the provided configuration. Once it has successfully created a container, we can see the list of the running containers using the second command:

As we observe from the job logs, the docker run has been executed successfully, and the running container has been listed with the container ID, image name used, ports mapped between container and host, volumes mounted, and status of the container.

With this, the required setup is completed for running our tests with Travis CI and Docker. The next step is to start sending the HTTP requests to this container on a specific port. We do this using the Maven command as shown below.

Here we are using the Maven build command along with TestNG to clean the repository and using the install phase with the command arguments such as the suite file, required browser to use, and the grid URL.

Since the Firefox container is running in the Travis CI instance on port 4444, we send the test requests to this port on the mentioned URL.

Once the Maven build is started, Travis CI downloads the required dependencies from the Maven central repository for the first time. Since we are using the cache configuration for Maven as below, it uses the cache for subsequent runs.

Therefore, Travis CI can cache the content for the build so that the build process can be sped up. In order to use this caching feature, we need to set the Build pushed branches to ON in the repository settings.

Once all the tests are executed on the browser which is available in the Docker container, we get the results and the build status as zero(0).

We have successfully performed our first Selenium test automation with Travis CI and Docker. If the build completes with an exit code as zero(0), it will be treated as passed. For many of us in Selenium test automation, it is required to see the test results to assess the regression suite quality. So we just added a phase in the travis.yml file to deploy the artifacts back to GitHub once the build is completed.

Since we have used TestNG in our Travis CI and Docker example, we get test execution reports in a clean and precise format in the target folder.

We are trying to deploy the index.html and emailable-report.html as per the below details.

Deploy phase details from the Travis CI build logs.

In order to publish the artifacts to GitHub, we need to create a personal access token from the GitHub developer settings page and add it to the environment variables section of the Travis CI repository. The same variable api_key is used in the deploy phase of our configuration.

That’s all! We are done with running one complete build in Travis CI with Docker. In the Build History section, we can see the whole history of test runs as below.

We can see the deployed artifacts in the Releases section on GitHub as below.

We can also run the tests in other browsers using the other browser containers. But, first, we need to update the before_install phase with the relevant run command in the travis.yml file.

Also need to update the -DgridHubURL in the maven command with a configured host port for each browser.

Using Docker Compose

In our previous Travis CI and Docker example, we have used Docker standalone images from Selenium and started running our tests in Travis CI with Docker. However, if you would have observed, adding each Docker run command in the travis.yml file is not fool-proof, and we need to update the travis.yml file for all the changes required on the browser end.

Instead, we could leverage the docker-compose utility tool from Docker itself. We can define all the browser-specific services required in a file called docker-compose.yml file and refer to it in the travis.yml file. It would really help us improve the readability of the build configuration file and separate the browser containers.

Using docker-compose we can use a single command to activate all the services in a single go. Also, docker-compose files are very easy to write as they also use the YAML syntax. All the services in docker compose can even be stopped with a single command.

We use the below docker-compose.yml file to define the services.

So now the new travis.yml configuration looks as below. Update the travis.yml file in the project with this file, and commit and push the code to start the new build in Travis CI and Docker using the new build configuration.

The only change here is that in the before_script phase, we are using docker-compose instead of running the direct docker commands. Instead, we use the curl utility to download the docker-compose file and save the content to a file named docker-compose.yml.

Once that is completed, we use the docker-compose up -d statement to start all the services. This command starts all the services in the compose file and starts listening to the requests on the mentioned ports. Then we use the docker-compose ps command to see the services that are started. Finally, we use the same maven command to point our tests and execute them using the Travis CI build job.

The below is the screenshot of the Travis CI logs, which shows that the docker-compose has successfully started the defined services.

Build log details while running the tests on the Chrome browser with the below maven command.

Build log details while running the tests on the Firefox browser with the below maven command.

As you have observed, we are using the same port for running the tests in Chrome and Firefox browsers. It is because we are leveraging the hub-node architecture of the Selenium Grid here. In our earlier Travis CI and Docker example, where we are running the stand-alone container, we haven’t used the hub container.

Run Selenium Tests With Zalenium And Travis CI

As per our previous examples of using Selenium, Travis CI, Docker images to run the tests, we can clearly see that we always need to update the versions as and when a new version is out. This becomes an overhead, as we need to spend a lot of time updating the configurations.

If you search for an alternative, you might come across a solution called Zalenium. Zalenium is a flexible and scalable container-based Selenium Grid with video recording, live preview, basic auth & dashboard. It provides all the latest versions of browser images, drivers, and tools required for Selenium test automation. It also has a provision to send the test requests to a third-party cloud provider if the browser requested is not available in the setup.

Let’s see how we can use them together using Docker images and with Docker compose.

Using Docker Images

In order to use Zalenium, we need to pull the two images as specified below. Once those images are available, start the container using the Docker run command with the necessary options.

Use the below travis.yml file to configure the build using Docker images for Zalenium.

Also, we have made use of environment variables options available in Travis CI to dynamically pass the values at run time for TestNG XML file name, browser, and grid hub URL. We can set these values as below in the Settings section of the project.

Once the execution is started, we can observe in the logs that the Travis CI system has read the environment variables and passed them to the running build.

Next, the required Docker images are pulled from the central registry, and the Docker run command runs. Finally, the command docker ps shows the running containers at the moment.

The required browser container is started on port 4444, and the tests will be executed successfully. We can see the test execution status as below.

Similarly, we can change the browser value to GRID_FIREFOX and trigger a new build.

Once the execution for GRID_FIREFOX is started, the Travis CI system will read the environment variables and pass them to the running build.

The required browser container is started on port 4444, and the tests will be executed successfully. We can see the test execution status as below.

Using Docker Compose

We can also leverage Docker compose and Zalenium here to quickly spin up a scalable container-based Selenium Grid and run our tests.

The below is the docker-compose.yml file with the required services. Here we are starting two services, Selenium and Zalenium, and listening to the incoming requests on port 4444.

The complete travis.yml file, in this case, is as below.

Once the build has started, we can see the log details as below. After that, required services will be started, and the tests are executed.

Run Selenium Tests With Selenium Cloud using Travis CI

From all our previous examples, it is evident that we can use Travis CI, Docker, and Selenium together to create automation regression pipelines with ease. As per our requirement, we can configure the declarative YAML files – travis.yml & docker-compose.yml as per our requirement, trigger the build, and get the results. However, there is one drawback with all our previous examples.

Let’s say if we want to see the regression execution live as it is happening, it is not possible, at least in the community version of Travis CI. On the enterprise version, along with some additional configuration, we could achieve this. Also, if we wanted to check the logs – driver logs, network logs, etc.-. we have to make changes to our examples that required additional effort again. Is there a solution to this problem? The answer is YES! We have LambdaTest cloud-based Selenium grid to our rescue.

LambdaTest is a cross browser testing cloud platform to perform automation testing on 3000+ combinations of real browsers and operating systems. It is very easy to configure a project using LambdaTest and start leveraging the benefits out of it. Let’s integrate our project examples with the LambdaTest cloud grid and see how it’s working.

We try to understand both options – using Docker images and starting the services using the docker-compose.

Using Docker Images

To start with the LambdaTest, first, navigate to the LambdaTest registration page and sign-up for a new account. Once the LambdaTest account is activated, go to the Profile> section and note the LambdaTest Username and LambdaTest Access key. We will need these LambdaTest Username and Access keys to execute our tests on the LambdaTest platform.

We use the below travis.yml file to run our tests with Travis CI and Docker on the LambdaTest cloud grid.

• Before triggering the build, we need to ensure that the below environment variables are set in the project settings in Travis CI.

  LT_USERNAME - Username from the LambdaTest profile page.

  LT_ACCESS_KEY - Access key obtained from the LambdaTest profile page.

  Below should be the form of gridHubURL.

  Where is the Username, is the Access key from LambdaTest account.

  

  Once the build starts, Travis CI reads the configured environment variables.

  

  As per the travis.yml file configuration, the respective Docker images are pulled, and containers are started.

  

  We are using the Docker run command with the flag lambdatestEnabled as true. Because of this, Zalenium starts the hub on port 4444 and one custom node using docker-selenium. A cloud proxy node is registered to the grid since we enabled the cloud integration with the LambdaTest platform. Once the test request is received, it will be sent to the available node with all the capabilities to execute the tests.

  Once Travis CI completes the Selenium test automation execution, we can navigate to the Automation dashboard of LambdaTest to see our test execution in the Timeline view. Click on the test case; we would be navigated to the Automation logs screen to see other details such as execution recording, logs, etc.

  

  

  Next, let’s do the same using the docker-compose.

• Using Docker Compose

  It’s pretty much the same as our previous examples with minor modifications. Here is the docker-compose.yml file we use to integrate our tests with the LambdaTest cloud grid.

• The configuration is almost similar to previous Travis CI and Docker examples, except that we are configuring the lambdatestEnabled flag to true for the start command. And adding the environment variables for LambdaTest username and access keys using LT_USERNAME and LT_ACCESSKEY. Also, please make sure that the environment variables in the Travis CI project are still intact and available during the build.

• 

  The build result would be similar as the services are created by docker-compose, and the test execution happens on the browser containers in LambdaTest.

  Parallel Testing With Travis CI, Docker And LambdaTest

  Till now, we have been discussing running the Selenium UI tests sequentially using multiple options with Travis CI, Docker, and LambdaTest. But as the application enhances we will have more tests in the testing suite. And as the size of the testing suite is big, the time it takes to execute will also be more.

  If the execution time is more than we are not meeting the primary goal of test automation, we need to provide early feedback on the product quality to the development team. So how do we achieve this goal without compromising on the testing scope?

  The answer is to run the tests in parallel mode wherever feasible to reduce the execution time drastically.

  Coming back to our discussion, let us make some changes to the testng.xml file as below to support parallel test execution. Add the required changes in a new file called testng-parallel.xml and add them to our project. We are using the parallel attribute of testNG with a value of tests and configuring the tests to run in parallel with a thread count of 2. As you observe, we are configuring the file to run our tests in Chrome and Firefox browsers from the LambdaTest cloud platform.

  

  If we go back to our LambdaTest automation dashboard, we can observe that two sessions are started as the job is executed. One session is for a chrome browser and one for a firefox browser. Also, we can observe that we are using 2 of 5 parallel sessions in the LambdaTest platform – which indicates that our tests are being executed in parallel mode.

  

  Like this, we could play around with configurations available in TestNG, Docker, and LambdaTest and build efficient and robust Selenium test automation suites.

  Conclusion

  In this post, we have covered some of the important concepts in Travis CI and Docker to build the pipelines for performing the Selenium test automation. We have also discussed integrating our test suites with the LambdaTest cloud grid and leveraging it in our Selenium test automation efforts. and build robust CI/CD pipelines using Travis CI, Docker, and LambdaTest. There are many more exciting features that you can try upon and explore.

  Let us know in the comments if you want to have another article on the same topic with advanced capabilities.

  Happy Testing and Travis-ci-ing!

    dist: trusty
    language: java
  
    jdk:
      - oraclejdk8
  
    before_script:
      - docker run -d -p 4444:4444 -v /dev/shm:/dev/shm selenium/standalone-firefox:4.0.0-rc-1-prerelease-20210618
      - docker ps
  
    script:
      - mvn clean install -DsuiteXmlFile=testng.xml -Dbrowser=GRID_FIREFOX -DgridHubURL=http://localhost:4444/wd/hub
  
    cache:
      directories:
        - .autoconf
        - $HOME/.m2
  
    deploy:
      provider: releases
      api_key: ${api_key}
      skip_cleanup: true
      file: [ "target/surefire-reports/emailable-report.html",
              "target/surefire-reports/index.html" ]
      on:
        all_branches: true
        tags: false
  

    mvn clean install -DsuiteXmlFile=testng.xml -Dbrowser=GRID_FIREFOX -DgridHubURL=http://localhost:4444/wd/hub
  

    <!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
    <suite name="All Test Suite">
        <test verbose="2" name="travisci-selenium-docker-lambdatest">
            <parameter name="browser" value="GRID_CHROME">
                <parameter name="gridHubURL"
                           value="http://localhost:4444/wd/hub"/>
            </parameter>
            <classes>
                <class name="com.lambdatest.SeleniumTests">
                    <methods>
                        <include name="verifyHeader1"/>
                        <include name="verifyHeader2"/>
                        <include name="verifyFirstElementBehavior"/>
                        <include name="verifySecondElementBehavior"/>
                        <include name="verifyAddButtonBehavior"/>
                    </methods>
                </class>
            </classes>
        </test>
    </suite>
  

    package com.lambdatest;
  
    import org.openqa.selenium.By;
    import org.openqa.selenium.WebElement;
    import org.testng.annotations.AfterTest;
    import org.testng.annotations.BeforeTest;
    import org.testng.annotations.Test;
  
    import static org.assertj.core.api.Assertions.assertThat;
  
    public class SeleniumTests extends BaseTest {
  
        @BeforeTest
        public void setUp() {
            driver.get("https://lambdatest.github.io/sample-todo-app/");
        }
  
        @Test(priority = 1)
        public void verifyHeader1() {
            String headerText = driver.findElement(By.xpath("//h2")).getText();
            assertThat(headerText).isEqualTo("LambdaTest Sample App");
        }
  
        @Test(priority = 2)
        public void verifyHeader2() {
            String text = driver.findElement(By.xpath("//h2/following-sibling::div/span")).getText();
            assertThat(text).isEqualTo("5 of 5 remaining");
        }
  
        @Test(priority = 3)
        public void verifyFirstElementBehavior() {
            WebElement firstElementText = driver.findElement(By.xpath("//input[@name='li1']/following-sibling::span[@class='done-false']"));
            assertThat(firstElementText.isDisplayed()).isTrue();
            assertThat(firstElementText.getText()).isEqualTo("First Item");
  
            assertThat(driver.findElement(By.name("li1")).isSelected()).isFalse();
            driver.findElement(By.name("li1")).click();
            assertThat(driver.findElement(By.name("li1")).isSelected()).isTrue();
  
            WebElement firstItemPostClick = driver.findElement(By.xpath("//input[@name='li1']/following-sibling::span[@class='done-true']"));
            assertThat(firstItemPostClick.isDisplayed()).isTrue();
  
            String text = driver.findElement(By.xpath("//h2/following-sibling::div/span")).getText();
            assertThat(text).isEqualTo("4 of 5 remaining");
        }
  
        @Test(priority = 4)
        public void verifySecondElementBehavior() {
            WebElement secondElementText = driver.findElement(By.xpath("//input[@name='li2']/following-sibling::span[@class='done-false']"));
            assertThat(secondElementText.isDisplayed()).isTrue();
            assertThat(secondElementText.getText()).isEqualTo("Second Item");
  
            assertThat(driver.findElement(By.name("li2")).isSelected()).isFalse();
            driver.findElement(By.name("li2")).click();
            assertThat(driver.findElement(By.name("li2")).isSelected()).isTrue();
  
            WebElement secondItemPostClick = driver.findElement(By.xpath("//input[@name='li2']/following-sibling::span[@class='done-true']"));
            assertThat(secondItemPostClick.isDisplayed()).isTrue();
  
            String text = driver.findElement(By.xpath("//h2/following-sibling::div/span")).getText();
            assertThat(text).isEqualTo("3 of 5 remaining");
        }
  
        @Test(priority = 5)
        public void verifyAddButtonBehavior() {
            driver.findElement(By.id("sampletodotext")).clear();
            driver.findElement(By.id("sampletodotext")).sendKeys("Yey, Let's add it to list");
            driver.findElement(By.id("addbutton")).click();
            WebElement element = driver.findElement(By.xpath("//input[@name='li6']/following-sibling::span[@class='done-false']"));
            assertThat(element.isDisplayed()).isTrue();
            assertThat(element.getText()).isEqualTo("Yey, Let's add it to list");
        }
  
        @AfterTest
        public void teardown() {
            if (driver != null) {
                driver.quit();
            }
        }
    }
  

Continuous Integration/Continuous Deployment (CI/CD) has become an essential part of modern software development cycles. As a part of continuous integration, the developer should ensure that the Integration does not break the existing code because this could lead to a negative impact on the overall quality of the project. In order to show how the integration process works, we’ll take an example of a well-known continuous integration tool, TeamCity. In this article, we will learn TeamCity concepts and integrate our test suites with TeamCity for test automation by leveraging LambdaTest's cloud-based Selenium grid.

There are numerous best CI/CD tools available for building high-quality code and narrowing the gap between development and impacted teams. Besides establishing a DevOps culture in the organizations, teams enhance it by implementing best CI/CD practices throughout the Software Development Life Cycle(SDLC). These practices help the teams accelerate product development, automate processes, and improve overall productivity.

Please head over to the original article for detailed information.

Introduction

As per Microsoft's official documentation, candidates for this exam should have foundational knowledge of cloud services and how those services are provided with Microsoft Azure. The exam is intended for candidates who are just beginning to work with cloud-based solutions and services or are new to Azure. The exam skills outline is as below:

• Describe cloud concepts
• Describe core Azure services
• Describe core solutions and management tools on Azure
• Describe general security and network security features
• Describe identity, governance, privacy, and compliance features
• Describe Azure cost management and Service Level Agreements

Microsoft has recently changed the content of AZ-900 exam in November, 2020. So always refer the official documentation for syllabus and other details.

Let me explain my preparation plan and the materials I have covered.

Preparation

I already have some exposure towards using cloud technologies, most specifically AWS and Google Cloud. I am a Google certified Cloud Engineer as well as Cloud Architect. Hence I am already equipped with the cloud concepts and services being used. This preparation has given me an opportunity to explore Azure and understand different services provided.

1. Microsoft official learning path for AZ-900

I started with following the Microsoft's official learning path for AZ-900

The below are the step-wise tutorials:

• Azure Fundamentals part 1: Describe core Azure concepts
• Azure Fundamentals part 2: Describe core Azure services
• Azure Fundamentals part 3: Describe core solutions and management tools on Azure
• Azure Fundamentals part 4: Describe general security and network security features
• Azure Fundamentals part 5: Describe identity, governance, privacy, and compliance features
• Azure Fundamentals part 6: Describe Azure cost management and service level agreements

Advantages:

• Since this is a tutorial we have the flexibility to complete at our own pace
• The quizzes in each section test our knowledge on each topic
• With the help of detailed examples and use cases, we can understand the concepts easily
• Each topic is focusing on one area of the Azure platform
• Some of the tutorials also give us practical learning experience with the pre-configured azure services

2. Microsoft Azure Fundamentals Certification Free Course (AZ-900) by Exam Pro

After getting acquainted with the basics of Azure platform and services, I have completed the below video course from Exam Pro.

• AZ 900 Free Course by Exam Pro

Advantages:

• Andrew Brown - the author of the course has covered most of the exam syllabus in just 3 hours!
• It can be a refresher before the exam
• Exam guide walkthrough

3. Self-Practice

Next step in my preparation plan is to have some hands-on experience using services provided by Azure. I have created a free azure account and explored different services such as Azure Virtual machines, App functions, different SQL database services etc. This really gave me a feel of using that specific service with the knowledge I got from my theoretical lessons mentioned above.

4. Exam Topics

Finally, I have went through some of the practice exams on AZ-900 to get a feel of the exam and questions. Notable resource in this area would be Exam Topics website. There are 150+ free practice questions for this exam. One thing to remember is that the answer mentioned in the website may not always be correct. We need to go through all the discussions section for each question, use our knowledge and come to a conclusion on the answer.

Other materials:

I have also used some of the other materials/blogs as mentioned below:

• Awesome Azure Github repo
• Study Guide by Vlad

Exam overview and experience

I have completed all the above steps as discussed. It took me around one week of time(working full-time) even being a certified cloud engineer by other provider(GCP). I have practiced a lot to get more hands-on experience on many services.

I have chosen to appear for the exam at a Pearson exam center near to my location

• I have got 41 questions(Multiple choice, multi-select, drag-drop) that need to be answered in 90 minutes
• Since this is an entry level exam - I feel that the exam is easy, given good preparation. So you need to manage time efficiently as per your preparation
• There are no questions on using commands with Azure CLI
• After submitting the exam we get a PASS/FAIL result with the marks achieved out of 1000. Microsoft also gives a detailed overview of the percentage of marks obtained in each of section. We can also take a print of that, if needed
• Immediately we also receive a confirmation email with a certificate

You may have a look at my certificate here

Conclusion

Thank you for reading this far. I hope my experience is helpful for those who are trying to apply and prepare for AZ-900 exam.

Wishing you all the best for your certification journey.

Prerequisites:

This article assumes you have some idea of what docker is and how to use it. The pre-requisites to get started are:

• Docker running in your machine

If you are completely new to docker, I would highly recommend starting from here.

Installation Steps:

• Create a folder called build and add a Dockerfile in it with content as below.

# build/Dockerfile
FROM jenkins/jenkins:lts-alpine

USER root 
RUN apk add docker

• Create a docker-compose.yml as below:

#docker-compose.yml

version: "3.8"

services:
  jenkins:
    build: build/
    ports: 
      - 8090:8080
    volumes:
      - "jenkins.data:/var/jenkins_home"
      - "/var/run/docker.sock:/var/run/docker.sock"

volumes:
  jenkins.data:

• Run the below command to start the service:

docker-compose up -d

• Open the browser at:

localhost:8090

• We get a jenkins screens as below for the initial administrator password

• Get the password from:

docker-compose exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

• After entering the password from above step, Jenkins shows the plugin selection screen.

After the successful installation of the required plugins you will be redirected to Jenkins Dashboard page. You may create an admin user if required.

That's it. You can use Jenkins now to create and run jobs as long as the container is running :)

Introduction

As per Google Cloud's official documentation,

A Professional Cloud Architect enables organizations to leverage Google Cloud technologies. With a thorough understanding of cloud architecture and Google Cloud Platform, this individual can design, develop, and manage robust, secure, scalable, highly available, and dynamic solutions to drive business objectives.

The Google Cloud Architect should be able to:

• Design and plan a cloud solution architecture
• Manage and provision the cloud solution infrastructure
• Design for security and compliance
• Analyze and optimize technical and business processes
• Manage implementations of cloud architecture
• Ensure solution and operations reliability

How it's different from a Cloud Engineer exam ?

Cloud Engineer exam focusses on the tasks that cloud engineers perform such as - creating virtual machines, configuring instance groups, assigning roles to identities, monitoring the VM's and so on. This exam is more likely to have detailed questions about commands using gcloud, gsutil and bq.

Where as the Cloud architect exam is focused more on the candidate's ability to perform tasks such as - identifying which storage option is best, designing an architecture that meets necessary regulatory requirements, or understanding the implications of horizontally scaling a database. Architects should also be familiar with the command options, but a detailed knowledge on the command options is not necessary. As per my experience it is unlikely that we get questions on using the GCP commands in the exam.

Let me explain my detailed preparation plan for the Cloud Architect exam.

I also have shared similar experiences about Cloud Engineer exam here.

1. Google Learning path from Coursera

I have started my preparation with the Google recommended official learning path as below. If followed in the same order, it gives you a very good understanding of different services that GCP provides and role of an architect in leveraging the services for building solutions.

• Google Cloud Platform Fundamentals: Core Infrastructure
• Essential Google Cloud Infrastructure: Foundation
• Essential Google Cloud Infrastructure: Core Services
• Elastic Google Cloud Infrastructure: Scaling and Automation
• Reliable Google Cloud Infrastructure: Design and Process
• Preparing for the Google Cloud Professional Cloud Architect Exam

There is an overlap between the Cloud Engineer and Cloud Architect exams. Hence you would have already completed some of the above courses as part of Cloud Engineer exam preparation.

If you have some prior experience working with AWS then you may optionally take a look at the below courses. This course enables you to make a smoother transition from AWS comparing the services from both platforms:

• Google Cloud Platform Fundamentals for AWS Professionals

Suggested Hands-On Labs from Qwiklabs are:

• Cloud Architecture
• Cloud Architecture - Design, Implement, and Manage

Advantages:

• Flexibility to complete at our own pace
• The quizzes in each section test our knowledge on each topic
• Topic wise slides and official documentation references will be provided
• Each course is focusing on one area of the GCP platform
• Qwiklabs quests gives us a great practical learning experience

2. Google Cloud Architect Study Guide from Dan Sullivan

I already have experiences using Dan Sullivan's study guides on GCP. The study guide on Cloud Engineer exam has helped me immensely to understand all the basics of GCP. It is one of the key factor for my success in exam as well as my experience with using GCP. So, selecting the similar guide for Cloud Architect exam was also an obvious choice for me. I really like his writing style and level of details.

This book covers all the exam objectives - enabling us to design network, storage, and compute resources; meet all business and technical requirements; design for security and compliance, plan migrations; and much more! It is fully equipped with numerous practice questions for each section which helps us to prepare for our success in the exam.

Advantages:

• Covers all the exam objectives
• Review questions at the end of each chapter & one practice test
• Detailed explanation about the sample case studies
• Clearly distinguish the design architectures for business and technical requirements
• Explains about the overall SRE(Software Reliability Engineering) ideology
• Discusses about cloud migration approaches

3. Qwiklabs

After acquiring the theoretical knowledge I started working on different quests in Qwiklabs. This has really helped to practice more in real-time and gave me confidence on using different GCP services. I highly suggest the Visual Map of Qwiklabs GCP Quests created and maintained by Chris F. This article has a map of different quests that are available in GCP. It really helps the beginners to focus on respective areas and learn accordingly. As I already have got some experience using GCP, I tried to complete only the quests where I need more hands-on and deep understanding.

Advantages:

• Practical experience !!!

4. Awesome GCP videos by Sathish VJ

Sathish VJ has put a lot of effort in creating the video playlists for most of the GCP exams. I have completed his playlist on Cloud Architect for this exam. As part of these videos Sathish takes the questions from official practice set and discusses on the concept as well as answering part. The logical answering approaches towards any kind of question is really important for the exam - as the question may come from any corner of the whole GCP services. I would suggest any GCP aspirant to go through the videos before attempting any exam.

There is also an active GitHub repo for all the information related to GCP. This can the single point of source of information for anything on GCP.

Advantages:

• Can be a refresher before the exam
• Tips on finding the best answers

5. Google SRE book

Google has published a series of books on explaining how it maintains and runs its production systems(Gmail, YouTube etc.). Site Reliability Engineering - SRE is one such book which is really helpful for understanding the overall process behind SRE ideology and relevant practices. The books are available online for free reading and it really contains some of the best ideas and methods for architecting a solution.

Advantages:

• Best SRE practices
• Available online for free reading

Exam overview and experience

I have completed all the above steps as discussed. It took me around two months of time(working full-time) even being a certified cloud engineer. I have practiced a lot to get more hands-on experience on many services.

I have chosen to appear for the exam at a Kriterion exam center near to my location.

• The exam consists of 50 questions(Multiple choice & multi-select) that need to be answered in 120 minutes.
• The exam pattern is mostly similar to Cloud Engineer exam - the only difference is that we get some questions from the sample case studies(Mountkirk Games,Dress4Win and TerramEarth).
• Questions are bit complex and contains huge information as compared to Cloud engineer exam. So you need to manage time efficiently.
• There are very less number of questions on using commands(at least for me there is no question !)
• After submitting the exam we get a preliminary PASS/FAIL result.
• If passed, Google will send a confirmation email with in a week time along with a certificate.

For all professional level certifications, Google also send us a code to purchase any merchandise from it's store.

You may have a look at my certificate here

Conclusion

Hope my experience helps anyone trying to apply for the Cloud Architect exam. Wishing you all the best for your certification journey.

Thank you !

Contents

Introduction

Pre-requisites

Option - 1: Running Postgres with direct docker commands

Option - 2: Running Postgres with docker compose

Running multiple instances of postgres in the same host

Conclusion

Introduction

PostgreSQL is an open-source, object-relational database management system (ORDBMS). It is also commonly referred as Postgres. As a database server, its primary function is to store data, supporting best practices and retrieve it later. Developers opt for this relational database as it is free, stable and flexible.

Deploying Postgres in a container is cost-efficient in terms of infrastructure, it also supports CI/CD development, and streamlines deployment and application management.

Pre-requisites

This article assumes you have some idea of what docker is and how to use it. The pre-requisites to get started are:

• Docker daemon running in your machine
• Account has been created in docker hub

If you are completely new to docker, I would highly recommend starting from here.

We could either choose to run postgres with direct docker commands or use a declarative docker-compose file

Option - 1: Running Postgres with direct docker commands

Pull Postgres image from Docker Hub

To download a particular image, or set of images (i.e., a repository), use docker pull. If no tag is provided, Docker Engine uses the :latest tag as a default. The docker pull command syntax is

docker pull [OPTIONS] NAME[:TAG|@DIGEST]

Run the below command on terminal to pull the postgres image from docker hub

$ docker pull postgres

You would see the below outcome if the action is successful

$ docker pull postgres
Using default tag: latest
latest: Pulling from library/postgres
d121f8d1c412: Already exists
9f045f1653de: Pull complete
fa0c0f0a5534: Pull complete
54e26c2eb3f1: Pull complete
cede939c738e: Pull complete
69f99b2ba105: Pull complete
218ae2bec541: Pull complete
70a48a74e7cf: Pull complete
c0159b3d9418: Pull complete
353f31fdef75: Pull complete
03d73272c393: Pull complete
8f89a54571bf: Pull complete
4885714928b5: Pull complete
3060b8f258ec: Pull complete
Digest: sha256:0171a93d62342d2ab2461069609175674d2a1809a1ad7ce9ba141e2c09db1156
Status: Downloaded newer image for postgres:latest
docker.io/library/postgres:latest

You could verify the local cache of the images available on the system using the below command.

$ docker images
REPOSITORY                       TAG                 IMAGE ID            CREATED             SIZE
postgres                         latest              817f2d3d51ec        2 days ago          314MB

Start the Postgres container

Now that the postgres image is on our system, we need to use the docker run command to start the container using the image that we just downloaded. The syntax for docker run is as follows

docker run --name [container_name] -e POSTGRES_PASSWORD=[your_password] -d postgres

Create a docker volume as below

$ docker volume create --name=pgdata

Use the below command to start the postgres container using the postgres:latest image we just downloaded. We run it with couple of parameters like port, volumes etc.

$ docker run --rm --name pg-docker -e POSTGRES_PASSWORD=password -d -p 5432:5432 -v $HOME/docker/volumes/postgres:/var/lib/postgresql/pgdata  postgres

After running the above command we should be getting a hash value of the container just started. As you observe, we have provided various options to the docker run command:

• --rm: This informs the docker to automatically remove the container and it’s associated file system upon exit. If we are running so many short term containers, it is a good practice to pass rm flag to the docker run command for automatic cleanup and avoid disk space issues(this will be a life saver!). We can anyway use the -v option to persist data beyond the lifecycle of a container
• --name: An identifier for the container. We can choose any name we want. Note that two existing (even if they are stopped) containers cannot have the same name. In order to re-use a name, you would either need to pass the rm flag to the docker run command or explicitly remove the container by using the command docker rm [container name]
• -e: Exposes environment variable of name POSTGRES_PASSWORD with value password to the container. This environment variable sets the superuser password for PostgreSQL. We can set POSTGRES_PASSWORD to anything we like. There are additional environment variables you can set. These include POSTGRES_USER and POSTGRES_DB. POSTGRES_USER sets the superuser name. If not provided, the superuser name defaults to postgres. POSTGRES_DB sets the name of the default database to setup. If not provided, it defaults to the value of POSTGRES_USER
• -d: Launches the container in a detached mode or in other words, in the background - so that we could use the terminal for other operations
• -p: Binds port 5432 on localhost to port 5432 within the container. This option enables applications running out side of the container to be able to connect to the Postgres server running inside the container
• -v: Mounts $HOME/docker/volumes/postgres on the host machine to the container side volume path /var/lib/postgresql/pgdata created inside the container - here pgdata is the docker volume that we created earlier. This ensures that postgres data persists even after the container is removed

There are other options also available for docker run. For a complete list of options please check here

Verify the active instance of the postgres server using:

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
62f6afbe7802        postgres            "docker-entrypoint.s…"   3 seconds ago       Up 2 seconds        0.0.0.0:5432->5432/tcp   pg-docker

Connect to the postgres DB

The command syntax to connect to any container is:

docker exec -it [container_name] psql -U [postgres_user]

• If you are using these steps in a windows machine

First we need to connect to the postgres container in-order to do some work

$ docker exec -it pg-docker bash
root@62f6afbe7802:/#

As you have observed, now we have root access to the container. You may also notice the container ID that we have been using since starting.

Now we change the user to postgres which is the default super user created by default for us.

$ root@62f6afbe7802:/# su postgres
postgres@62f6afbe7802:/$

Once logged in with the postgres user, run the psql command as below

$ postgres@62f6afbe7802:/$ psql
psql (13.0 (Debian 13.0-1.pgdg100+1))
Type "help" for help.

Now we are in the psql interactive session, so that we could use all the postgres related activities.

For example to check the connection information issue the below command

$ postgres=# \conninfo
You are connected to database "postgres" as user "postgres" via socket in "/var/run/postgresql" at port "5432".

To create a new database with name testdb run this

$ postgres=# create database testdb;
CREATE DATABASE

In-order to list all the available databases use this

$ postgres=# \l
                                 List of databases
   Name    |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges
-----------+----------+----------+------------+------------+-----------------------
 postgres  | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
 template0 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
 testdb    | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
(4 rows)

postgres=#

As you observe, the newly create database testdb is present in the list. Similarly you can run other psql commands and use the DB for development and management tasks.

Use exit multiple times to come out of different shells

$ postgres=# exit
postgres@62f6afbe7802:/$ exit
exit
root@62f6afbe7802:/# exit
exit
$

Please refer this for some of the commonly used actions within psql

You can also connect with a GUI client like Dbweaver, PgAdmin etc.

Please note that you may observe issues while connecting to postgres server running in docker container in windows. As per the issue we need to first stop the existing postgres window service if any, to proceed with login.

• If you are using these steps in a linux machine

Follow these steps for Linux machine - most of them are similar with minor modifications (tested in Ubuntu 16.04 LTS)

$ sudo docker exec -it pg-docker psql -U postgres
psql (13.0 (Debian 13.0-1.pgdg100+1))
Type "help" for help.

$ postgres=# \conninfo
You are connected to database "postgres" as user "postgres" via socket in "/var/run/postgresql" at port "5432".
postgres=# create database testdb;
CREATE DATABASE
postgres=# \l
                                 List of databases
   Name    |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges   
-----------+----------+----------+------------+------------+-----------------------
 postgres  | postgres | UTF8     | en_US.utf8 | en_US.utf8 | 
 template0 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
 testdb    | postgres | UTF8     | en_US.utf8 | en_US.utf8 | 
(4 rows)

postgres=#

We could also just run the docker run command as above, without having to pull the image separately. Docker will pull the required image if its not present in the local cache

Option - 2: Running Postgres with docker compose

Instead of running all the docker commands individually, we can leverage docker-compose file to start the postgres service. It provides us a way to specify all the required configuration parameters declaratively in a file.

Ensure you have the docker-compose installed and available. It not please follow the steps here to get it

Create a docker-compose file

• To ensure an easy and clean installation, we first create a new folder named postgres and move into that folder

  $ mkdir postgres
  $ cd postgres
  

• Next we use the docker-compose file to download the postgres image and get the service up and running. Using your favorite utility to create a YAML file as below(using nano/powershell)

  $ nano docker-compose.yml
  

  OR

  $ ni docker-compose.yml
  

• Add the below content to the docker-compose file and save

version: "3.8"

services:
  db:
    image: postgres
    restart: always
    environment:
      - POSTGRES_DB=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=password
    ports:
      - "5432:5432"
volumes:
  pgdata:
    external: true

The YAML configuration outlines the below:

• version: file format version for docker-compose

• services: defines a service in compose file with name db

• image: uses the postgres image that uses the tag latest by default

• restart: specifies a restart policy for how a container should or should not be restarted on exit.

• environment: used to specify the environment variables used for starting the services

• ports: 5432 is the default port number for PostgreSQL. We map the port 5432 from container to the same port on host machine

• volumes: directive that mounts the source directories or volumes from host machine at target paths inside the container.

Please ensure to use the correct YAML file syntax. Would suggest to use the Visual Studio code to validate the file syntax before starting the service.

Start the postgres container with docker-compose

• Run the below command to start the container using the -d flag

$ docker-compose up -d

• You can check the logs with the command

$ docker-compose logs -f

That's it! Now you are ready to use the postgres DB in your development activities. Use the same steps as mentioned above to connect to the DB.

Finally, use the below to stop the postgres service

$ docker-compose stop

In-order to find the required image in the repository use the below steps

Search for a specific image in docker hub

Once you sign-up for the docker hub account, you can start using those credentials in terminal. Issue the below command to login to docker hub with your user details.

$ docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: rakeshvardan
Password:
Login Succeeded

If you are not familiar with the image name, you can even search the entire docker public repository as below and choose the appropriate images(always suggested to use official images from respective product teams)

$ docker search postgres
NAME                                    DESCRIPTION                                     STARS               OFFICIAL            AUTOMATED
postgres                                The PostgreSQL object-relational database sy…   8383                [OK]

Running multiple instances of postgres in the same host

We can start multiple postgres containers in the same host and use different versions of the servers for local development.

$ docker run --rm  --name pg-docker-dev -e POSTGRES_PASSWORD=devpassword -d -p 5432:5432 -v $HOME/docker/volumes/postgresdev:/var/lib/postgresql/pgdata  postgres

$ docker run --rm  --name pg-docker-qa -e POSTGRES_PASSWORD=qapassword -d -p 5433:5432 -v $HOME/docker/volumes/postgresqa:/var/lib/postgresql/pgdata  postgres

As you can see, we started 2 different postgres databases for 2 environments - one for development and another for testing. Once started you can use these DB's independently of each other. We have also mounted two different folders(postgresdev and postgresqa) for each of the database to persist the data in the host machine. A different port 5433 on the host is mapped for the qa DB. You can also use two different versions of postgres on the same machine if you have a requirement to do so.

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
48b82d7dc83f        postgres            "docker-entrypoint.s…"   14 seconds ago      Up 12 seconds       0.0.0.0:5433->5432/tcp   pg-docker-qa
e9814264368a        postgres            "docker-entrypoint.s…"   42 seconds ago      Up 40 seconds       0.0.0.0:5432->5432/tcp   pg-docker-dev

Conclusion

I hope that now you got a basic idea on how to get started using postgres with docker. So next time whenever you are trying to install any software try checking for respective docker images and start using them. You will have lot of fun.

Thank you !

References

• Docker hub repo for postgreSQL
• How To Deploy PostgreSQL On Docker Container
• Don’t install Postgres. Docker pull Postgres