Forem: mhossen

FizzBuzz: if…else if vs continue (and why order matters)

mhossen — Sun, 24 Aug 2025 17:47:09 +0000

FizzBuzz is one of the first exercises many developers learn. The rules are simple:

Print numbers from 1 to 100
If the number is divisible by 3, print “Fizz”
If the number is divisible by 5, print “Buzz”
If the number is divisible by both 3 and 5, print “FizzBuzz”

It looks straightforward, but the way you structure the conditions makes a difference. Let’s look at two approaches: using if...else if and using continue.

What does divisible really mean?

When we say “divisible,” we mean the number divides evenly without leaving a remainder. In C#, we use the modulo operator % to check for remainders.

For example:

6 % 3 == 0   // true, because 6 divided by 3 has no remainder
10 % 5 == 0  // true, because 10 divided by 5 has no remainder
7 % 3 == 1   // false, remainder is 1

So when you see if (i % 3 == 0), it means “if the number can be divided by 3 with no remainder.”

The if…else if approach

The most common way is to chain conditions together.

for (int i = 1; i <= 100; i++)
{
    if (i % 3 == 0 && i % 5 == 0)
        Console.WriteLine("FizzBuzz");
    else if (i % 3 == 0)
        Console.WriteLine("Fizz");
    else if (i % 5 == 0)
        Console.WriteLine("Buzz");
    else
        Console.WriteLine(i);
}

Here, the else if structure ensures that only one condition runs for each number.

Why check for both first?

If we wrote the code like this instead:

if (i % 3 == 0)
    Console.WriteLine("Fizz");
else if (i % 5 == 0)
    Console.WriteLine("Buzz");
else if (i % 3 == 0 && i % 5 == 0)
    Console.WriteLine("FizzBuzz");

Then a number like 15 would match the first condition (i % 3 == 0) and stop there. It would print “Fizz” and never reach “FizzBuzz.” That is why we check for the most specific condition first.

Think of it like a decision tree:

Is the number divisible by 3 and 5 (no remainder)?
   Yes -> FizzBuzz
   No ->
      Is it divisible by 3 (no remainder)?
         Yes -> Fizz
         No ->
            Is it divisible by 5 (no remainder)?
               Yes -> Buzz
               No -> Just print the number

The continue approach

Another way is to write each condition separately and use continue to move on to the next number once a match is found.

for (int i = 1; i <= 100; i++)
{
    if (i % 3 == 0 && i % 5 == 0)
    {
        Console.WriteLine("FizzBuzz");
        continue;
    }

    if (i % 3 == 0)
    {
        Console.WriteLine("Fizz");
        continue;
    }

    if (i % 5 == 0)
    {
        Console.WriteLine("Buzz");
        continue;
    }

    Console.WriteLine(i);
}

In this version, each condition is independent. Once one is true, the continue keyword skips the rest and goes straight to the next loop iteration.

Which style is better?

Both approaches work.

if...else if is a bit cleaner when conditions are mutually exclusive.
continue keeps conditions separate and avoids nesting, but it does require a little more repetition.

For something as small as FizzBuzz, it comes down to personal preference. What matters most is making sure the conditions are in the right order.

Final thought

When I first tried FizzBuzz, I made the mistake of checking i % 3 == 0 before checking for both 3 and 5. As a result, “FizzBuzz” never printed. That small mistake taught me the importance of writing conditions in the right order.

And always remember: divisible means there should be no remainder.

No matter which style you use, always check the most specific case first.

Rethinking the Test Pyramid: A Balanced View from Code to Customer

mhossen — Tue, 12 Aug 2025 22:43:24 +0000

When we talk about automated testing, the Test Pyramid often comes up. This is a popular model introduced by Mike Cohn. While it provides a solid foundation for designing test strategies in software development, it is time we evolve the conversation.

When we factor in real-world business impact and modern testing tools, the classic pyramid starts to look a bit too one-dimensional.

🧱 The Classic Test Pyramid (Mike Cohn)

The original Test Pyramid encourages teams to write:

✅ Many fast, isolated unit tests
🟡 Some mid-level integration tests
🔺 Few slow and brittle UI/end-to-end tests

The idea is that unit tests offer the fastest feedback loop, and E2E tests should be used sparingly to keep CI pipelines efficient.

🧠 But What About Business Perspective?

While the traditional pyramid optimizes for engineering speed and cost, it does not always align with what really matters to the business or the end user.

From that angle, things flip.

Why?

While unit tests help reduce technical risk, they do not fully answer the business's biggest question: Can users actually complete key workflows like registering, shopping, or submitting a claim without issues? That is where end-to-end testing really delivers confidence.

Integration tests also play an important role by verifying how components work together. However, because they often rely on mocked dependencies, they do not always reflect real-world scenarios. They help reduce systemic risk but still stop short of validating complete user workflows.

🔀 E2E Is Not Just “UI Testing”

Another common misconception is that E2E means just clicking through the UI.

That is only part of the picture. A well-designed E2E test should:

Use APIs to create test data
Interact with the UI to simulate real user flows
Verify backend changes through DB or API assertions
Perform efficient cleanup
Validate business rules, not just user interface elements

✅ Modern E2E tests are hybrid by design. They use the right tool for each layer while focusing on validating real user value.

🧪 Example: Placing an Order

Instead of bloated UI-only flows, consider this smarter E2E approach:

Precondition: Seed test user and product catalog via API
UI Flow: Login and checkout using Playwright or Selenium
Assertions:
- UI shows confirmation
- Database contains the new order
- API returns the correct order status
Teardown: Delete or reset test data using an API call

This is still an end-to-end test, but it is faster, cleaner, and more reliable.

⚖️ The Balanced Approach: Engineering and Business Confidence

We do not have to choose one pyramid over the other. Instead, we can layer them together:

Goal	Strategy
Fast development feedback	Unit and service-level tests
Regression protection	Integration and smoke tests
Business confidence	High-value E2E tests
User-centered quality	Simulated real-world workflows

🚀 Takeaways

The Test Pyramid still holds value, especially for speed and scalability in engineering.
But do not ignore the inverted business view, where E2E tests bring the most confidence.
And please, do not treat E2E as just UI automation. Great E2E tests combine API, database, and UI validation to provide robust, focused proof that your system works where it matters most.

Quality is not just about passing unit tests. It is about proving that your system works where it matters most: in the hands of your users.

Java Clean Code Tip for Testers: Use try-with-resources Like a Pro

mhossen — Tue, 03 Jun 2025 20:32:25 +0000

When writing Java tests—be it for automation, backend validation, or reading test data—you'll often deal with resources like files, streams, or database connections. Managing these resources properly is crucial to prevent issues like memory leaks or file locks.

Let's explore how try-with-resources, introduced in Java 7, can help you write cleaner and safer code.

😬 The Traditional Way (Before Java 7)

BufferedReader reader = null;
try {
    reader = new BufferedReader(new FileReader("data.csv"));
    String line;
    while ((line = reader.readLine()) != null) {
        // process line
    }
} catch (IOException e) {
    e.printStackTrace();
} finally {
    if (reader != null) {
        try {
            reader.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

This approach is verbose and error-prone. Forgetting to close resources can lead to resource leaks.

✅ The Modern Way: try-with-resources

try (BufferedReader reader = new BufferedReader(new FileReader("data.csv"))) {
    reader.lines().forEach(System.out::println);
} catch (IOException e) {
    System.err.println("Error reading file: " + e.getMessage());
}

With try-with-resources, Java automatically closes the resource at the end of the statement, even if exceptions occur. This leads to cleaner and more reliable code.

👩‍💻 Why Testers Should Care

As a tester, you might:

Read test data from files
Write logs during test execution
Interact with databases
Handle input/output streams

Using try-with-resources ensures that these resources are properly closed, reducing the risk of resource leaks and making your tests more robust.

🧪 Real-World Example: Logging in Tests

Here's a utility class to write logs:

import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;

public class TestLogger {

    public static void writeLog(String message, String path) {
        try (BufferedWriter writer = new BufferedWriter(new FileWriter(path, true))) {
            writer.write(message);
            writer.newLine();
        } catch (IOException e) {
            System.err.println("Could not write log: " + e.getMessage());
        }
    }
}

Usage in a test:

@Test
public void testUserLogin() {
    TestLogger.writeLog("Login test started", "logs/test-log.txt");
    // perform test steps
    TestLogger.writeLog("Login test passed", "logs/test-log.txt");
}

This approach ensures that the BufferedWriter is closed properly after writing, even if an exception occurs.

🔄 Handling Multiple Resources

You can manage multiple resources in a single try-with-resources statement:


try (
    InputStream inStream = new FileInputStream("input.txt");
    OutputStream outStream = new FileOutputStream("output.txt")
) {
    byte[] buffer = new byte[1024];
    int length;
    while ((length = inStream.read(buffer)) > 0) {
        outStream.write(buffer, 0, length);
    }
} catch (IOException e) {
    e.printStackTrace();
}

Resources are closed in the reverse order of their declaration.

🧠 TL;DR

Use try-with-resources for any resource that implements AutoCloseable (e.g., files, streams, database connections).
It simplifies your code and improves test reliability.
Cleaner code leads to fewer bugs and better maintenance. 🧼

What I Learned in a Decade of Experience in Test Automation

mhossen — Wed, 01 Jan 2025 07:54:38 +0000

Let’s start with the big question that many people ask: which programming language should you choose for automation?

Everyone seems to have a favorite. Whether it’s JavaScript, Python, Java, or C#, people often swear by the language that has worked best for them. But here’s the truth: all programming languages have the same foundational principles. They differ in syntax, libraries, and how they handle certain tasks, but the building blocks remain the same.

That said, some languages are undeniably better suited for certain tasks. Some execute faster, others are easier to set up, and some are more beginner-friendly. My advice? Pick one language and focus on mastering it. Don’t try to learn too many languages at once—it’s better to go deep than wide, especially early in your journey.

How Programming Languages Compare in Test Automation

The language you choose can impact the speed and ease of your test automation efforts. Here’s a simplified comparison of some popular languages for key testing criteria:

Language	Ease of Use	Cross-Platform Compatibility	Database Testing	UI Testing	API Testing
Python	Easy to learn, extensive libraries	Excellent	Excellent	Excellent	Excellent
Java	Moderate, verbose syntax	Excellent	Excellent	Excellent	Excellent
JavaScript	Easy, single language for web	Excellent	Good	Excellent	Excellent
C#	Moderate, great IDE support	Excellent	Excellent	Excellent	Excellent
Ruby	Easy, readable syntax	Good	Good	Excellent	Good

Don’t Chase Shiny Objects

One of my favorite quotes is:

“We are always chasing shiny objects.”

— Tim Corey

It’s tempting to switch to the latest language or framework whenever something doesn’t go as planned. But no language or tool is perfect. When you hit a roadblock—like a feature that isn’t supported or something that doesn’t work the way you expect—try to find a solution instead of jumping ship. The software industry thrives on problem-solving, and switching languages at every obstacle would make progress impossible.

Wrapping It Up

Test automation is about more than just tools and languages—it’s about solving problems. By mastering one language and learning the ins and outs of its frameworks, you’ll be equipped to handle most challenges that come your way. As you gain experience, you’ll be able to adopt new tools and languages with confidence, not because they’re trendy, but because they truly meet your needs.

Test Automation Best Practices

mhossen — Sun, 22 Dec 2024 16:16:02 +0000

Understanding Best Practices for Test Automation

Summary

Test automation is a critical strategy for efficiently managing the testing of large, complex systems. It helps establish a standardized process that minimizes human effort and ensures consistent quality across business and product offerings. When implemented correctly, automation provides stakeholders with confidence, freeing up Quality Assurance (QA) Engineers and Analysts to focus on high-value tasks such as exploratory testing. This approach enhances the overall quality of products and services delivered to consumers and clients.

Considerations Before Diving into Automation

Before embarking on your automation journey, address the following key questions to ensure alignment with your business and technical goals:

1. Why Pursue Automation Efforts?

Understanding the core reasons behind automating your tests ensures that your efforts are purposeful. These reasons might include:

Increasing test coverage
Improving test speed and efficiency
Enhancing the reliability of repeated tests

By identifying the "why," you can shape a strategy that solves real problems rather than adopting automation for the sake of trends.

2. What Business or Use Cases Justify Automation?

Evaluate if automation is genuinely needed or if manual testing suffices. Key indicators include:

High volume of repetitive tests (e.g., regression or smoke tests)
Frequent changes to critical features that require validation
Scalability needs that manual testing cannot address efficiently

3. How Will Automation Be Implemented?

Selecting the right implementation approach is critical. Common options include:

UI-Only Automation: Ideal for front-end testing but fragile with UI changes
API-Only Automation: Stable and faster, suited for testing business logic
Database Automation: Verifies data integrity across systems
Comprehensive Automation: Combines UI, API, and database testing for thorough coverage

Key Questions for Test Automation

Why Automate?

Test automation offers several benefits:

Increase Efficiency: Automate repetitive tasks to speed up testing and feedback loops
Improve Consistency: Eliminate human error with reliable execution
Enhance Test Coverage: Run a wider variety of tests more frequently
Scale Testing: Execute tests in parallel across multiple environments or browsers
Free Up Resources: Allow QA teams to focus on strategic, exploratory testing

What to Automate?

Identify areas where automation will have the most impact:

High-Priority, Repetitive Tests: Ideal for regression and smoke tests
Time-Consuming Tasks: Nightly builds or extensive regression tests
High-Risk Features: Critical features frequently updated
Performance and Load Testing: Simulate high user loads efficiently
Data-Driven Testing: Validate multiple input scenarios and edge cases

How to Implement Automation?

Follow these steps to create a robust automation strategy:

1. Define Clear Goals

Establish objectives such as improving test coverage, reducing testing time, or enabling frequent releases.

2. Choose the Right Tools

Select tools based on your tech stack and team expertise. Popular tools across programming languages include:

Web Testing: Selenium, Playwright, Cypress
API Testing: Postman, RestAssured, Karate
Mobile Testing: Appium, Espresso, XCUITest
Unit/Integration Testing: JUnit, NUnit, PyTest, Mocha
CI/CD: Jenkins, GitHub Actions, GitLab CI/CD, Azure DevOps

3. Design a Robust Test Framework

Leverage design patterns like Page Object Model or Data-Driven Testing to create modular, reusable, and maintainable scripts.

4. Integrate with CI/CD Pipelines

Automate tests within your Continuous Integration/Continuous Deployment pipeline to ensure tests run automatically on code changes, enabling rapid feedback.

5. Monitor and Report

Use reporting tools to:

Track test results
Monitor trends over time
Identify unstable tests

Conclusion

Implementing test automation requires a thoughtful approach to ensure it addresses real challenges and provides tangible benefits. By defining clear objectives, selecting the right tools, and adopting a robust framework, your team can achieve efficiency, reliability, and scalability in your testing process. Start small, iterate, and watch your testing efforts transform your development lifecycle.

Understanding Superclass vs. Request Decorator: Differences, Benefits, and Use Cases

mhossen — Mon, 16 Dec 2024 00:13:16 +0000

When working with object-oriented programming in Java, two commonly used patterns are superclasses and decorator patterns. Both promote code reuse but serve different purposes. In this article, we'll explore the differences, benefits, and use cases of using a decorator with a familiar example: an Animal class.

What is a Superclass?

A superclass is a base class that provides common attributes and behaviors for its derived classes (subclasses). The relationship is built using inheritance, where subclasses share or extend the functionality defined by the superclass.

Key Traits of a Superclass

Inheritance-based: Subclasses inherit attributes and behaviors directly.
Shared behavior: Encapsulates logic common to all derived classes.
Static relationship: The structure is determined at compile-time.

Example: Using Animal as a Superclass

class Animal {
    void eat() {
        System.out.println("This animal eats food.");
    }
}

class Dog extends Animal {
    void bark() {
        System.out.println("The dog barks.");
    }
}

public class SuperclassExample {
    public static void main(String[] args) {
        Dog dog = new Dog();
        dog.eat();  // Inherited from Animal
        dog.bark(); // Specific to Dog
    }
}

Here:

Animal is the superclass.
Dog inherits the eat behavior and adds its own functionality.

What is a Decorator?

A Decorator Pattern is a structural design pattern that dynamically adds new functionality to an object at runtime without altering its structure. It relies on composition rather than inheritance.

Key Traits of a Decorator

Composition-based: Wraps objects to extend or modify their behavior.
Dynamic behavior: Adds functionality at runtime.
Extensibility-friendly: Aligns with the Open/Closed Principle by allowing functionality extension without modifying existing code.

Example: Using Animal with a Decorator

Suppose you want to dynamically add new behaviors (like making the animal "fly" or "swim") to an existing Animal object without creating a new subclass for each behavior.

Decorator Implementation

interface Animal {
    void makeSound();
}

class BasicAnimal implements Animal {
    public void makeSound() {
        System.out.println("This animal makes a sound.");
    }
}

class FlyingAnimalDecorator implements Animal {
    private Animal animal;

    public FlyingAnimalDecorator(Animal animal) {
        this.animal = animal;
    }

    @Override
    public void makeSound() {
        animal.makeSound();
        System.out.println("It can also fly!");
    }
}

class SwimmingAnimalDecorator implements Animal {
    private Animal animal;

    public SwimmingAnimalDecorator(Animal animal) {
        this.animal = animal;
    }

    @Override
    public void makeSound() {
        animal.makeSound();
        System.out.println("It can also swim!");
    }
}

public class DecoratorExample {
    public static void main(String[] args) {
        Animal basicAnimal = new BasicAnimal();

        // Adding flying behavior
        Animal flyingAnimal = new FlyingAnimalDecorator(basicAnimal);
        flyingAnimal.makeSound();

        // Adding swimming behavior
        Animal swimmingAnimal = new SwimmingAnimalDecorator(basicAnimal);
        swimmingAnimal.makeSound();

        // Combining behaviors
        Animal flyingSwimmingAnimal = new SwimmingAnimalDecorator(flyingAnimal);
        flyingSwimmingAnimal.makeSound();
    }
}

Output

This animal makes a sound.
It can also fly!

This animal makes a sound.
It can also swim!

This animal makes a sound.
It can also fly!
It can also swim!

Superclass vs. Decorator

Aspect	Superclass	Decorator
Relationship	Inheritance (static relationship).	Composition (dynamic behavior).
Extensibility	Add functionality via subclasses.	Add functionality by wrapping objects.
Complexity	Simple and straightforward.	Slightly more complex due to composition.
When to Use	For shared behavior across related objects.	For customizing or extending the behavior of specific instances.
Coupling	Tightly coupled to the superclass.	Loosely coupled, more flexible.

When to Use vs. When Not to Use a Decorator

When to Use a Decorator

Dynamic Behavior Customization:

Add or combine behaviors for specific objects without creating multiple subclasses.
Flexible Extensibility:

Easily introduce new behaviors (e.g., "flying" or "swimming") without altering the base class.
Reusable Logic:

Encapsulate behaviors that can be applied to different types of objects.
Adherence to SOLID Principles:

Especially the Open/Closed Principle—extend functionality without modifying existing code.

When Not to Use a Decorator

When Behavior is Fixed:

If all objects of a class share the same behavior, a decorator may be overkill.
Performance Sensitivity:

Wrapping objects may introduce slight overhead.
When Simplicity Matters:

For straightforward cases, inheritance (superclasses) might be simpler and easier to manage.

Benefits of Using a Decorator

Dynamic Behavior Addition:

Decorators allow you to add functionality to individual objects without altering their structure or creating new subclasses.
Modularity:

Behaviors are encapsulated in separate decorator classes, making them easier to manage and test.
Behavior Combination:

You can stack multiple decorators to combine behaviors dynamically.
Avoids Subclass Explosion:

No need to create numerous subclasses for every possible combination of behaviors.

When to Use a Superclass Instead

While decorators shine in scenarios requiring flexibility, superclasses are better suited for:

Stable, Shared Behavior:

When all subclasses share the same behavior (e.g., all Dog objects can "bark").
Simpler Use Cases:

When the relationship between objects is straightforward and unlikely to change.

Wrapping Up

Choosing between a superclass and a decorator depends on your use case:

Use a superclass for fixed, shared behaviors across related objects.
Use a decorator for flexibility, dynamic behavior, or combining features without modifying existing code.

In our Animal example, superclasses worked well for shared traits like eating or barking. On the other hand, decorators allowed dynamic additions like flying or swimming without altering the base class. Both patterns are powerful—pick the one that fits your design needs!

Streamline Java Object Initialization with Inline Blocks (Including Public Fields)

mhossen — Wed, 04 Dec 2024 22:56:52 +0000

When creating objects in Java, balancing simplicity, maintainability, and flexibility can be challenging. Developers often resort to techniques like constructors, the Builder pattern, or factory methods. While effective, these approaches can add unnecessary complexity for simple, one-off objects.

Enter inline initialization blocks, a concise way to initialize both private fields (via setters) and public fields directly within the object creation context. In this blog, we’ll explore how to use this technique effectively, even when public fields are involved.

What Are Inline Initialization Blocks?

Inline initialization blocks in Java use double curly braces ({{ }}) to configure an object immediately after instantiation. This approach simplifies object setup without requiring additional constructors or boilerplate code. Here’s an example:

Updated Code with Public Fields

public class SampleInlineInitialization {

  public static void main(String[] args) {
    Person person = new Person() {{
      setName("John Smith");
      setAge(25);
      setGender("Male");
      setAddress("123 Main St.");
      setEmail(getName() + "@gmail.com");
      // Public fields
      city = "San Francisco";
      state = "CA";
    }};

    System.out.println(person);
  }

  public static class Person {
    private String name;
    private int age;
    private String gender;
    private String address;
    private String email;
    public String city;
    public String state;

    @Override
    public String toString() {
      return new StringBuilder()
              .append("{")
              .append("\"age\": ").append(this.getAge())
              .append(", \"name\": ").append(this.getName())
              .append(", \"gender\": ").append(this.getGender())
              .append(", \"address\": ").append(this.getAddress())
              .append(", \"email\": ").append(this.getEmail())
              .append(", \"city\": ").append(this.city)
              .append(", \"state\": ").append(this.state)
              .append("}").toString();
    }

    // Getters and setters
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public int getAge() { return age; }
    public void setAge(int age) { this.age = age; }
    public String getGender() { return gender; }
    public void setGender(String gender) { this.gender = gender; }
    public String getAddress() { return address; }
    public void setAddress(String address) { this.address = address; }
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }
  }
}

Output:

{"age": 25, "name": John Smith, "gender": Male, "address": 123 Main St., "email": John Smith@gmail.com, "city": San Francisco, "state": CA}

Why Use Inline Initialization Blocks for Public Fields?

1. Flexibility for Public Fields

Inline initialization supports direct assignment to public fields without requiring a setter. For example:

city = "San Francisco";
state = "CA";

This keeps your code simple and avoids the need to define unnecessary setter methods for public fields.

2. Localized Configuration

All field assignments—whether private or public—are conveniently located within the object instantiation block. This improves readability and maintainability by keeping the configuration logic in one place.

3. Combines the Best of Both Worlds

Inline initialization allows you to:

Use setters for encapsulated private fields.
Assign public fields directly.

This dual capability makes it versatile for various scenarios.

Advantages of Using Inline Initialization Blocks

Eliminates Constructor Overloading

Instead of writing multiple constructors to handle various field combinations, you can configure fields dynamically at the point of object creation:

Person person = new Person() {{
  setName("John Smith");
  setAge(25);
  city = "San Francisco";
  state = "CA";
}};

Improves Readability

By centralizing the object setup, inline initialization eliminates confusion about where and how fields are being assigned.

Reduces Boilerplate Code

Say goodbye to redundant constructors and setters for every field. You can keep your class definition focused and clean.

Perfect for Prototyping

Inline initialization is ideal for quick prototyping, testing, or creating objects with one-off configurations.

When to Use Inline Initialization for Public Fields

While inline initialization is convenient, it’s best suited for:

Prototyping and Testing: Quickly set up objects without adding unnecessary methods.
One-Off Configurations: Perfect for use cases where the object won’t need complex or reusable initialization logic.
Lightweight Use Cases: Works well for small, simple objects where you want to minimize setup code.

Considerations for Public Fields

Use Public Fields with Caution

While public fields are straightforward, they may expose the class to unintentional misuse. Encapsulation via private fields and setters is generally safer for production code.

Debugging Anonymous Classes

Inline initialization creates an anonymous subclass of the target class. While this rarely affects runtime behavior, debugging tools may display the subclass name instead of the original class name, which could be confusing in large projects.

Wrapping Up

Inline initialization blocks are a powerful way to simplify object creation in Java. By supporting both private and public field assignments, they strike a balance between flexibility and simplicity.

This approach eliminates the need for overloaded constructors, enhances readability, and reduces boilerplate code. Whether you’re prototyping, testing, or creating lightweight objects, inline initialization can save you time and effort while keeping your code clean and maintainable.

Efficient Data Sharing in SpecFlow Steps: A Cleaner Approach for Improved Maintainability

mhossen — Sat, 07 Oct 2023 22:11:16 +0000

Keywords: SpecFlow, data sharing, ScenarioContext, constructor injection, cleaner code, maintainability

Introduction

When working with SpecFlow, a popular BDD framework for .NET, efficient data sharing between steps is essential. While many developers rely on constructor injection for this purpose, this practice can lead to complex and hard-to-maintain code. In this technical blog post, we'll explore an alternative approach that not only streamlines data sharing but also minimizes the risk of data leaks.

Sharing Data Using ScenarioContext

In SpecFlow, the ScenarioContext class plays a pivotal role in facilitating data sharing. It functions as a versatile dictionary, allowing developers to store and retrieve objects associated with a particular scenario.

public abstract class BaseStep
{
    protected readonly ScenarioContext ScenarioContext;

    protected BaseStep(ScenarioContext scenarioContext)
    {
        ScenarioContext = scenarioContext;
    }
}

As shown in the code snippet above, we have a base step class that takes a ScenarioContext parameter in its constructor, granting access to the ScenarioContext within our step classes.

Data Sharing Without Constructor Injection

Instead of injecting data via constructor parameters, we can leverage the ScenarioContext directly to share data between steps. Let's dive into a practical example.

[Binding]
public sealed class AddNewUserSteps : BaseStep
{
    public AddNewUserSteps(ScenarioContext scenarioContext) : base(scenarioContext)
    {

    }

    [When(@"I create a user")]
    public void WhenICreateAUser()
    {
        // Arrange
        var user = new User
        {
            FirstName = "John",
            LastName = "Doe",
            Email = "jDoe@example.com"
        };

        // Store the user object in the ScenarioContext
        ScenarioContext.Set(user);

        // Act
        // Implement actions to create the user via UI, API, or database
    }
}

Within the WhenICreateAUser method, we create a User object and store it in the ScenarioContext using the ScenarioContext.Set method. This enables other steps within the same scenario to access this shared data.

Retrieving Data Without Constructor Injection

Now, let's see how we can effortlessly retrieve the user object in another step without the need for constructor parameter injection.

[Binding]
public sealed class UserAdminSteps : BaseStep
{
    public UserAdminSteps(ScenarioContext scenarioContext) : base(scenarioContext)
    {

    }

    [Then(@"I verify the new user is listed on the admin page")]
    public void ThenIVerifyNewUserIsListedOnTheAdminPage()
    {
        // Arrange
        // Retrieve the user object from the ScenarioContext
        var user = ScenarioContext.Get<User>();

        // Assert
        // Implement logic to verify the user's presence on the admin page
        user.FirstName.Should().Be("John");
    }
}

In the ThenIVerifyNewUserIsListedOnTheAdminPage method, we employ the ScenarioContext.Get method to retrieve the user object from the ScenarioContext. This grants seamless access to data shared in a previous step.

Benefits of Not Using Constructor Injection

By eschewing constructor injection and capitalizing on ScenarioContext, developers can reap several advantages:

Code Simplification: The code becomes more straightforward and cleaner, eliminating the need to pass data through constructors and making it highly readable and maintainable.
Enhanced Flexibility: Data can be shared between steps with unparalleled flexibility, enabling effortless modification and extension of the data sharing logic.
Mitigated Data Leakage Risk: Data sharing is confined within the scope of a scenario, significantly reducing the likelihood of data leakage between different scenarios or tests.

Conclusion

In this technical blog post, we've unraveled an efficient methodology for sharing data between SpecFlow steps without resorting to constructor injection. By harnessing the power of ScenarioContext, you can streamline your code, bolster its flexibility, and minimize the risk of data leaks. This approach empowers you to craft cleaner and more maintainable SpecFlow scenarios while ensuring that data is readily accessible where it's needed.

Leveraging Interfaces and Dependency Injection for Flexible Code: A Practical Specflow Example

mhossen — Sat, 03 Jun 2023 14:20:58 +0000

Introduction:
Interfaces and dependency injection (DI) are powerful tools in software development that promote flexibility, testability, and maintainability. In this blog post, we'll explore a practical example that demonstrates how interfaces and DI can be used effectively. We'll analyze the code, explain its usage, and highlight the benefits it brings to the project.

Understanding the Code

Let's dive into the provided code snippet, which showcases the usage of interfaces and DI in a Selenium-based login page scenario. The code consists of several classes: ILoginPage, LoginPage, ContainerExtension, LoginSteps, StepBase, and Hooks. We'll discuss each component and its role in the overall implementation.

`ILoginPage` Interface

The ILoginPage interface defines the contract for a login page. It declares two methods: NavigateToLoginPage() and Login(string username, string password). This interface establishes the required behavior for any login page implementation.

public interface ILoginPage
{
  void NavigateToLoginPage();
  void Login(string username, string password);
}

`LoginPage` Class

The LoginPage class implements the ILoginPage interface and represents the actual login page. It extends a BasePage class and includes private properties that represent various elements on the page, such as the username input field, password input field, and login button. The class also provides implementations for the interface methods.

The LoginPage constructor accepts an IWebDriver parameter, which is passed from the DI container during object creation. This approach enables loose coupling between the LoginPage and the IWebDriver implementation, making the class more flexible and easier to test.

internal class LoginPage : BasePage, ILoginPage
{
  private IWebElement UserName => Driver.FindElement(By.Id("username"));
  private IWebElement Password => Driver.FindElement(By.Id("password"));
  private IWebElement LoginButton => Driver.FindElement(By.CssSelector("input[value='Login']"));

  public LoginPage(IWebDriver driver) : base(driver)
  {
  }

  public void NavigateToLoginPage()
  {
    var location = typeof(LoginPage).Assembly.Location;
    var parent = Directory.GetParent(location);
    Driver.Navigate().GoToUrl(@$"{parent}\Sample\login.html");
  }

  public void Login(string username, string password)
  {
    UserName.SendKeys(username);
    Password.SendKeys(password);
    LoginButton.Click();
  }
}

`ContainerExtension` Class

The ContainerExtension class extends the functionality of an IObjectContainer (a DI container implementation) by introducing a method named RegisterTypes<TBase>(). This method utilizes reflection to scan the assembly for all types derived from TBase (in this case, BasePage).

For each derived type found, the code checks if there is an interface named I{derivedType.Name} (e.g., ILoginPage for LoginPage). If a matching interface is found, an instance of the derived type is created using the provided arguments and registered with the DI container using the interface as the registration key.

public static class ContainerExtension
{
  public static void RegisterTypes<TBase>(this IObjectContainer container, params object[] args) where TBase : class
  {
    var typeOfBase = typeof(TBase);

    var derivedTypes = typeOfBase.Assembly.GetTypes()
      .Where(t => typeOfBase.IsAssignableFrom(t) && t is {IsClass: true, IsAbstract: false});

    Parallel.ForEach(derivedTypes, derivedType =>
    {
      var @interface = derivedType.GetInterfaces().FirstOrDefault

(i => i.Name == $"I{derivedType.Name}");
      if (@interface == null) return;

      var obj = Activator.CreateInstance(derivedType, args);
      container.RegisterInstanceAs(obj, @interface);
    });
  }
}

`LoginSteps` Class

The LoginSteps class represents a set of steps defined for a specific behavior-driven development (BDD) framework, such as SpecFlow. It includes a constructor that accepts an IObjectContainer and an ILoginPage instance, which are resolved through DI.

These steps correspond to scenarios defined in the BDD feature files. For example, the GivenINavigateToLoginPage() step calls the NavigateToLoginPage() method on the injected ILoginPage instance.

private readonly ILoginPage _loginPage;

public LoginSteps(IObjectContainer container, ILoginPage loginPage) : base(container)
{
  _loginPage = loginPage;
}

[Given(@"I navigate to login page")]
public void GivenINavigateToLoginPage()
{
  _loginPage.NavigateToLoginPage();
}

[Given(@"I provide '(.*)' and '(.*)'")]
public void GivenIProvide(string username, string password)
{
  _loginPage.Login(username, password);
}

`StepBase` Class

The StepBase class serves as a base class for step definitions in a BDD framework. It includes a constructor that accepts an IObjectContainer, allowing derived classes to access the DI container.

public abstract class StepBase : TechTalk.SpecFlow.Steps
{
  protected readonly IObjectContainer Container;

  protected StepBase(IObjectContainer container)
  {
    Container = container;
  }
}

`Hooks` Class

The Hooks class includes methods decorated with SpecFlow attributes, such as [Before] and [After]. These methods are executed before and after each scenario, providing setup and teardown functionality.

In the BrowserSetup() method, a new instance of the Selenium IWebDriver is created, and it is registered with the DI container using RegisterInstanceAs(). Additionally, RegisterTypes<BasePage>() is called on the DI container, which scans the assembly for all types derived from BasePage and registers them as instances with their corresponding interfaces.

The BrowserTearDown() method disposes of the IWebDriver instance retrieved from the DI container.

[Binding]
public class Hooks
{
  private readonly IObjectContainer _container;

  protected Hooks(IObjectContainer container)
  {
    _container = container;
  }

  [Before(Order = 0)]
  public void BrowserSetup()
  {
    var driver = Driver.CreateBrowserSession();
    _container.RegisterInstanceAs(driver);
    _container.RegisterTypes<BasePage>(_container.Resolve<IWebDriver>());
  }

  [After(Order = 99)]
  public void BrowserTearDown()
  {
    _container.Resolve<IWebDriver>().Dispose();
  }
}

Usage and Benefits

To use the code sample, follow these steps:

Define your own classes implementing the ILoginPage interface, representing different login page implementations.
Update the RegisterTypes<BasePage>() call in the BrowserSetup() method of the Hooks class to include your custom page implementations.
Use the LoginSteps class to define step definitions for your BDD scenarios, injecting the ILoginPage instance through the constructor.

By leveraging interfaces and DI in this manner, you gain the following benefits:

Flexibility: Interfaces allow you to switch between different login page implementations without modifying the consuming code.
Testability: DI enables easy injection of mock objects for

testing purposes, facilitating unit testing of classes dependent on the ILoginPage interface.

Code Reusability: The LoginSteps class serves as a reusable component for defining login-related steps in multiple scenarios, promoting code reuse and reducing duplication.
Loose Coupling: DI decouples classes from specific implementation details, making it easier to replace dependencies and promoting modular, decoupled code.

By incorporating interfaces and DI into your projects, you can achieve cleaner, more modular code that is easier to maintain, test, and extend. The code provided in this blog post demonstrates practical usage and highlights the benefits of these concepts.

Conclusion

Interfaces and dependency injection are powerful tools that enhance code flexibility, testability, and maintainability. By leveraging interfaces to define contracts and DI to inject dependencies, you can write cleaner, modular code that is easier to maintain and test.

The code example showcased the usage of interfaces to define the contract for a login page and how DI can be employed to inject the ILoginPage instance into the LoginSteps class. Additionally, the code demonstrated how the ContainerExtension class extends the DI container's functionality to register implementations based on interfaces.

By adopting these practices in your own projects, you can improve code quality, support future scalability, and promote code reuse.

GitHub Interface Example: selenium_specflow_di_interface_example

Simplifying Dependency Management with SpecFlow's IObjectContainer - Part 2

mhossen — Thu, 01 Jun 2023 01:38:14 +0000

Note: This is an updated version of our previous article, Simplifying Dependency Management with SpecFlow's IObjectContainer: Part 1.

Introduction

Welcome to this blog post where we will delve deeper into the art of simplifying dependency management within SpecFlow by harnessing the power of constructor injection. In Part 1, we covered the fundamentals of constructor injection and its advantages. In this updated installment, we will explore this topic more comprehensively, providing additional insights and addressing key questions related to dependency injection in SpecFlow.

Why Embrace Dependency Injection?

Dependency injection is a pivotal software design pattern that champions loose coupling and code modularization. By embracing dependency injection, we can decouple the creation and management of dependencies from the core logic of our application. This decoupling paves the way for more straightforward testing, enhanced maintainability, and the flexibility to swap out implementations seamlessly.

How Does Dependency Injection Function in SpecFlow?

SpecFlow, as a behavior-driven development (BDD) testing framework, offers its very own dependency injection framework named IObjectContainer. By leveraging IObjectContainer, we can effortlessly implement constructor injection within our SpecFlow step classes. IObjectContainer seamlessly takes care of resolving and injecting dependencies, rendering our code more modular and test-friendly.

Grasping the Code

Let's revisit the code snippet we explored in Part 1:

[Binding]
public class LoginSteps : StepBase
{
  private readonly LoginPage _loginPage;

  public LoginSteps(IObjectContainer container, LoginPage loginPage) : base(container)
  {
    _loginPage = loginPage;
  }

  [Given(@"I navigate to login page")]
  public void GivenINavigateToLoginPage()
  {
    _loginPage.NavigateToLoginPage();
  }

  [Given(@"I provide '(.*)' and '(.*)'")]
  public void GivenIProvide(string username, string password)
  {
    _loginPage.Login(username, password);
  }
}

In this revised code, we've transformed the LoginSteps class to embrace constructor injection. The constructor now accepts two parameters: an instance of IObjectContainer and an instance of LoginPage. Thanks to SpecFlow's IObjectContainer framework, these dependencies are resolved and provided automatically when creating a LoginSteps instance. This eliminates the need for manual dependency resolution via the GetPage<TPage>() method from the StepBase class.

Advantages of Constructor Injection

Implementing constructor injection in SpecFlow yields numerous advantages:

Enhanced Testability: Constructor injection simplifies the process of supplying mock implementations for testing purposes. This facilitates more effective and isolated unit testing.
Cleaner Code: Dependencies are explicitly defined and supplied during object creation, enhancing code readability and maintainability.
Superior Separation of Concerns: Dependency injection separates the responsibility of managing dependencies from the core application logic, encouraging a modular and loosely coupled design.

Conclusion

By embracing constructor injection within SpecFlow, we streamline dependency management, elevate the testability, and enhance the maintainability of our SpecFlow tests. SpecFlow's IObjectContainer framework handles dependency resolution and injection automatically. Constructor injection promotes cleaner code, improved separation of concerns, and simplified testing processes. Embrace this approach to simplify your SpecFlow projects and reap the benefits it offers. Stay tuned for Part 2, where we'll delve even deeper into this topic!

Simplifying Dependency Management with SpecFlow's IObjectContainer: Part 1

mhossen — Mon, 29 May 2023 18:33:10 +0000

Using Concrete Class Example

Introduction:

In modern software development, managing dependencies is crucial for building scalable and maintainable applications. In this blog post, we will explore the importance of dependency management and how SpecFlow's IObjectContainer can streamline the process. We'll dive into your provided code example to understand why using IObjectContainer is beneficial, how to register dependencies using reflection, and the purpose of using a container for dependency registration in SpecFlow steps. While we will use a Selenium Page Object Model (POM) example for illustrating the concepts, it's important to note that the approach can be used for any type of object registration based on the testing demands.

Why Use IObjectContainer?

SpecFlow's IObjectContainer serves as a dependency injection container, allowing for the easy management of dependencies in your SpecFlow tests. It helps achieve loosely coupled and modular code, promoting better testability, maintainability, and extensibility. By leveraging IObjectContainer, you can centralize dependency registration and resolve dependencies effortlessly.

How to Register Dependencies with Reflection

In the following code example, the SeleniumDemo.SpecFlow.Hooks.ContainerExtension class provides an extension method called RegisterTypes, which facilitates the registration of concrete classes using reflection.

public static class ContainerExtension
{
  public static void RegisterTypes<TBase>(this IObjectContainer container, params object[] args) where TBase : class
  {
    var typeOfBase = typeof(TBase);

    var derivedTypes = typeOfBase.Assembly.GetTypes()
      .Where(t => typeOfBase.IsAssignableFrom(t) && t.IsClass && !t.IsAbstract);

    Parallel.ForEach(derivedTypes, derivedType =>
    {
      var obj = Activator.CreateInstance(derivedType, args);
      container.RegisterInstanceAs(obj);
    });
  }
}

The RegisterTypes method takes a generic parameter, TBase, representing the base class from which the derived classes will be registered. It uses reflection to scan the assembly for types that are assignable from TBase, concrete, and non-abstract.

By iterating over the derived types, the RegisterTypes method creates an instance of each derived type with the specified arguments and registers it with the IObjectContainer using the RegisterInstanceAs method. This process eliminates the need for manual registration of each derived class, making it easier to maintain and extend the test suite.

Usage of Container for Dependency Registration in SpecFlow Steps

In SpecFlow, steps are the building blocks of behavior-driven tests. Each step definition class represents a set of steps that can be executed during a scenario. By leveraging the IObjectContainer within the StepBase class, you can effortlessly resolve dependencies required by these steps.

[Binding]
public class LoginSteps : StepBase
{
  public LoginSteps(IObjectContainer container) : base(container)
  {
  }

  [Given(@"I navigate to login page")]
  public void GivenINavigateToLoginPage()
  {
    GetPage<LoginPage>().NavigateToLoginPage();
  }

  [Given(@"I provide '(.*)' and '(.*)'")]
  public void GivenIProvide(string username, string password)
  {
    GetPage<LoginPage>().Login(username, password);
  }
}

In the LoginSteps class, the constructor accepts an IObjectContainer parameter, allowing the container to be injected into the step definitions. This enables the use of the GetPage<TPage> method, which resolves instances of concrete page classes derived from BasePage.

By utilizing the container to resolve page dependencies, you achieve better encapsulation and separation of concerns. The step definitions remain focused on the test logic, while the container handles the instantiation and management of page objects. This promotes maintainability and reusability, as any changes to the page classes can be easily propagated through the container.

Auto Creation and Disposal of Driver Object with Container

In this code example, the Hooks class demonstrates how to leverage the IObjectContainer for automatic creation and disposal of the driver object.

[Binding]
public class Hooks
{
  private readonly IObjectContainer _container;

  protected Hooks(IObjectContainer container)
  {
    _container = container;
  }

  [Before(Order = 0)]
  public void BrowserSetup()
  {
    var driver = Driver.CreateBrowserSession();
    _container.RegisterInstanceAs(driver);
    _container.RegisterTypes<BasePage>(_container.Resolve<IWebDriver>());
  }

  [After(Order = 99)]
  public void BrowserTearDown()
  {
    _container.Resolve<IWebDriver>().Dispose();
  }
}

The BrowserSetup method is executed before the scenarios and is responsible for creating the browser session. It calls the Driver.CreateBrowserSession method to obtain the driver object. The driver object is then registered with the IObjectContainer using the RegisterInstanceAs method, making it available for dependency resolution throughout the test execution.

The BrowserTearDown method is executed after the scenarios and is responsible for disposing of the driver object. It retrieves the driver object from the container using the Resolve method and calls the Dispose method to properly clean up resources.

By leveraging the IObjectContainer for driver object management, you ensure that the driver object is automatically created and disposed of, eliminating the need for manual management in each test scenario.

Conclusion

Dependency management is a critical aspect of software development, and SpecFlow's IObjectContainer provides a powerful tool for simplifying this process. By utilizing reflection and the container's registration capabilities, you can automate the registration of concrete classes, making your test suite more maintainable and extensible. Incorporating dependency injection into your SpecFlow steps promotes modular design and enhances collaboration between testers and developers. Embracing IObjectContainer empowers you to focus on writing expressive and efficient behavior-driven tests while enjoying the benefits of well-managed dependencies.

The Selenium Page Object Model example used in this blog post highlights how IObjectContainer can simplify dependency management for BDD approaches, but it's important to note that the approach can be applied to any type of object registration based on the testing demands. With SpecFlow and IObjectContainer, you never have to register a dependency manually again, allowing for a more efficient and seamless testing experience. Additionally, the provided code example demonstrates how to automatically create and dispose of the driver object using the IObjectContainer, further simplifying the setup and teardown process in your tests.

By embracing SpecFlow's IObjectContainer and leveraging its capabilities for dependency management, you can enhance the maintainability, extensibility, and efficiency of your behavior-driven tests.

GitHub: Selenium Specflow DI Concrete example

Simplify Web Automation with the WebDriver Extension for C#

mhossen — Thu, 25 May 2023 05:08:19 +0000

Web automation has become an essential part of modern software development and testing. One popular framework for web automation is Selenium WebDriver, which provides a powerful set of tools for interacting with web browsers. In this blog post, we will explore a C# extension method that enhances the capabilities of Selenium WebDriver by simplifying the process of locating elements using XPath.

Why use the WebDriver extension?

The WebDriver extension we will discuss offers several advantages over the standard WebDriver methods:

1. Simplified element location: The extension method allows you to locate elements using XPath in a more concise and readable manner. Instead of writing lengthy code to find elements, you can use the WithXPath method to locate them with a single line of code.

2. Automatic retries: The extension method incorporates a built-in retry mechanism, which can be useful when dealing with dynamic web pages or slow-loading elements. By specifying the maximum retry time and interval, you can ensure that the method waits for the element to become available before timing out.

3. Handling common exceptions: The extension method handles common exceptions that may occur during element location, such as TimeoutException, StaleElementReferenceException, and NoSuchElementException. This simplifies error handling and improves the reliability of your automation code.

How to use the WebDriver extension

To use the WebDriver extension in your C# project, follow these steps:

Step 1: Add the extension method to your project

Copy the provided C# code into a suitable location in your project, such as a helper class or a separate file.

public static IWebElement WithXPath<TDriver>(this TDriver driver, string xpath, int maxRetryInSeconds = 40,
      int retryIntervalInMilliseconds = 500) where TDriver : IWebDriver =>
      driver.WithActiveElement(By.XPath(xpath), maxRetryInSeconds, retryIntervalInMilliseconds);

private static IWebElement WithActiveElement(this IWebDriver driver, By locateBy, int maxRetryInSeconds = 40,
      int retryIntervalInMilliseconds = 500)
{
  var wait = new WebDriverWait(driver, TimeSpan.FromSeconds(maxRetryInSeconds))
  {
    PollingInterval = TimeSpan.FromMilliseconds(retryIntervalInMilliseconds),
    Message = $"Max element retry has reached at {maxRetryInSeconds} seconds",
  };

  wait.IgnoreExceptionTypes(new[]
    {typeof(TimeoutException), typeof(StaleElementReferenceException), typeof(NoSuchElementException)});

  return wait.Until(d =>
  {
    var element = d.FindElement(locateBy);

    if (!element.Displayed and !element.Enabled)
    {
      return null;
    }

    ((IJavaScriptExecutor) d).ExecuteScript("arguments[0].scrollIntoViewIfNeeded(true);", element);
    return element;
  }) ?? throw new WebDriverTimeoutException(wait.Message);
}

Step 2: Set up the WebDriver

Create an instance of the WebDriver in your test or automation code, such as ChromeDriver or FirefoxDriver.

// Set up the WebDriver
var driver = new ChromeDriver();

Step 3: Locate elements using XPath

Instead of using the standard WebDriver methods like FindElement(By.XPath(xpath)), you can now use the WithXPath extension method on your WebDriver instance. Simply pass the XPath expression as a parameter to the method.

Here's an example of how to use the WebDriver extension:

// Locate elements using XPath
var element = driver.WithXPath("//input[@id='username']");

In the above example, we use the WithXPath method to locate an input element with the id attribute equal to "username." The method will automatically retry until the element is found within the specified timeout.

Note: Null-coalescing operator (??) for C# 8+

As of C# 8, the null-coalescing operator (??) can be used to simplify the code and throw a WebDriverTimeoutException when the element is not found within the specified timeout. The null-coalescing operator works by returning the left-hand side expression if it is not null, or the right-hand side expression otherwise. In the case of the WebDriver extension, it can be used as follows:

return wait.Until(d =>
{
  var element = d.FindElement(locateBy);

  if (!element.Displayed && !element.Enabled)
  {
    return null;
  }

  ((IJavaScriptExecutor) d).ExecuteScript("arguments[0].scrollIntoViewIfNeeded(true);", element);
  return element;
}) ?? throw new WebDriverTimeoutException(wait.Message);

By using the null-coalescing operator, the Until method will return the found element if it is not null, or the throw new WebDriverTimeoutException(wait.Message) expression will be executed, throwing the exception with the specified message.

Conclusion

The WebDriver extension for C# simplifies the process of locating elements using XPath in Selenium WebDriver. With its concise syntax, built-in retry mechanism, and exception handling, the extension enhances the productivity and reliability of your web automation code. By incorporating this extension into your project, you can streamline your test automation efforts and improve the efficiency of your web application testing.

Forem: mhossen

FizzBuzz: if…else if vs continue (and why order matters)

Rethinking the Test Pyramid: A Balanced View from Code to Customer

🧱 The Classic Test Pyramid (Mike Cohn)

🧠 But What About Business Perspective?

Why?

🔀 E2E Is Not Just “UI Testing”

🧪 Example: Placing an Order

⚖️ The Balanced Approach: Engineering and Business Confidence

🚀 Takeaways

Java Clean Code Tip for Testers: Use try-with-resources Like a Pro

😬 The Traditional Way (Before Java 7)

✅ The Modern Way: try-with-resources

👩‍💻 Why Testers Should Care

🧪 Real-World Example: Logging in Tests

🔄 Handling Multiple Resources

🧠 TL;DR

What I Learned in a Decade of Experience in Test Automation

How Programming Languages Compare in Test Automation

Don’t Chase Shiny Objects

Wrapping It Up

Test Automation Best Practices

Understanding Best Practices for Test Automation

Summary

Considerations Before Diving into Automation

1. Why Pursue Automation Efforts?

2. What Business or Use Cases Justify Automation?

3. How Will Automation Be Implemented?

Key Questions for Test Automation

Why Automate?

What to Automate?

How to Implement Automation?

1. Define Clear Goals

2. Choose the Right Tools

3. Design a Robust Test Framework

4. Integrate with CI/CD Pipelines

5. Monitor and Report

Conclusion

Understanding Superclass vs. Request Decorator: Differences, Benefits, and Use Cases

What is a Superclass?

Key Traits of a Superclass

Example: Using Animal as a Superclass

What is a Decorator?

Key Traits of a Decorator

Example: Using Animal with a Decorator

Decorator Implementation

Output

Superclass vs. Decorator

When to Use vs. When Not to Use a Decorator

When to Use a Decorator

When Not to Use a Decorator

Benefits of Using a Decorator

When to Use a Superclass Instead

Wrapping Up

Streamline Java Object Initialization with Inline Blocks (Including Public Fields)

What Are Inline Initialization Blocks?

Updated Code with Public Fields

Why Use Inline Initialization Blocks for Public Fields?

1. Flexibility for Public Fields

2. Localized Configuration

3. Combines the Best of Both Worlds

Advantages of Using Inline Initialization Blocks

Eliminates Constructor Overloading

Improves Readability

Reduces Boilerplate Code

Perfect for Prototyping

When to Use Inline Initialization for Public Fields

Considerations for Public Fields

Use Public Fields with Caution

Debugging Anonymous Classes

Wrapping Up

Efficient Data Sharing in SpecFlow Steps: A Cleaner Approach for Improved Maintainability

Leveraging Interfaces and Dependency Injection for Flexible Code: A Practical Specflow Example

Understanding the Code

ILoginPage Interface

LoginPage Class

ContainerExtension Class

LoginSteps Class

StepBase Class

Hooks Class

`ILoginPage` Interface

`LoginPage` Class

`ContainerExtension` Class

`LoginSteps` Class

`StepBase` Class

`Hooks` Class