Blue-green deployment is a deployment strategy that minimizes downtime and risk by maintaining two production environments — blue and green. In this article, we will explore how to implement blue-green deployment using GitLab, covering each step from setup to rollback. How does it help –you are getting to test everything in a production like environment, not just in UAT and you can flip back and forth between two production environments to minimize down time.

How does it work — We need the following infrastructure in place:

1. GitLab Repository — you need something to store the code. We have chosen GitLab as the repository for this example.

2. CI/CD Pipeline — We will configure GitLab CI/CD pipeline to automate the build and deployment.

3. Load Balancer — This is required to switch between the blue and green environments. We will use any open-source tool for this. We will be using NGINX as the Load Balancer which will direct traffic to the blue environment by default. This ensures that users continue to access the stable version while you deploy and test the new version in the green environment.

The IP addresses for blue and green environment will need to be updated in the NGINX configuration file. At the same time, your DNS settings need to point the domain to NGINX server’s IP address.

4. Two Production Environments — Lastly, we need two environments which will be known as the blue and green environment.

Here is a flow to explain how it works in detail:

Stage 1 — At this stage, the two environments are set up with same version of code. Either of them can be used for same experience but all user traffic is directed to Blue environment at this point as in the picture at the left.

Stage 2 — This is when a new deployment happens. We will release the new version 1.1 into the Green environment to ensure user experience is not disturbed. Load balancer will still continue to direct all traffic to Blue as in the picture at the right.

We can configure GitLab CI/CD pipeline to build, test, and deploy your application. Use the .gitlab-ci.yml file to define the pipeline stages and jobs. Normally, we have to define the deployment stages in this file like build, test, deploy etc. Every step will have its own jobs and scrips to execute related actions automatically.

Stage 3 — At this stage load balancer will start directing some of the user traffic to Green. This will serve the purpose of beta testing also and entire traffic can be quickly diverted to Blue in case there is any problem with the new release. In the picture for Stage 3, we can see 40% of users have been moved to Green environment while 60% of them are still in Blue environment.

Stage 4 — At this stage the Load Balancer has completely moved all users into Green environment which is working as the active production environment. Blue can continue to have release 1.0 even at this stage.

Stage 5- At this stage a new release comes along. Version 1.2 which also contains updates code base for the previous version 1.1 is deployed into Blue environment using CI/CD pipeline. All users still continue to be using Green environment.

Stage 6- The load balancer once again starts directing users to the new production environment, which is Blue with the latest version 1.2. Eventually, 100% users move to Blue and the same cycle keeps repeating with every release.

Benefits

There are many benefits of using this blue green deployment strategy in this way.

Zero Downtime: Blue-green deployment allows updates to be rolled out without causing any downtime for users. While one environment (let’s say “blue”) is serving live traffic, the other environment (green) can be updated or modified. Once the changes are made and the green environment is ready, traffic can be seamlessly switched from the blue to the green environment.

Risk Reduction: By maintaining two identical environments, one serving live traffic and the other being updated, we are reducing the risk associated with deploying changes significantly. If any issues arise during deployment in the green environment, it can be easily rolled back by directing traffic back to the blue environment and vice versa. This rollback process can be performed quickly and with minimal impact on users.

Testing in Production-Like Environment: Blue-green deployment allows for thorough testing of updates in a production-like environment before they are made live. Users can be gradually directed to allow for Beta testing. This ensures that any potential issues or bugs are identified and addressed before the changes are exposed to all users.

Quick Rollback: If any issues are detected after deploying changes to the green environment, it’s straightforward to revert to the blue environment, which would still be running the previous stable version of the application. This rollback process can be automated as well in the CI/CD pipeline.

There are many ways to come up with a stable Blue Green environment set up. Some of the cloud providers like AWS come with sophisticated packages as well. Once integrated in the CI/CD pipeline this allows for automated and frequent deployments of updates to the application. Rolling deployments increase productivity of the team and also allow for quick fixes of bugs bringing in tremendous value to both quality and quantity of delivery.

If you liked my story, you could clap to help this reach more people and follow my profile @ Kaustav Singha Roy

Blue Green Deployment — How It Works was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scriptless test automation represents a complete shift in the world of software testing, empowering testers to create and execute automated tests efficiently and effectively, without the need for coding skills. Scriptless test automation, also known as codeless or no-code test automation, enables testers to design, execute, and maintain automated tests using intuitive graphical user interfaces (GUIs) instead of traditional scripting languages. This approach abstracts away the complexities of coding, allowing testers to focus on test design, functionality, and business logic.

We already have a few popular Scriptless test automation tools in the market that is gaining adoption. Two of these are TestCraft and Leapwork and we will see some comparisons between them in this article.

TestCraft

TestCraft is a cloud-based test automation platform that enables scriptless test automation. It allows users to create and execute automated tests without the need for coding or scripting. Here is a detailed explanation of how you can perform scriptless test automation using TestCraft.

➕ Setting Up TestCraft: TestCraft is easy to set up. Sign up for an account on the TestCraft platform. Once logged in, you’ll be directed to the dashboard where you can create new projects and tests.

➕ Creating a New Project: Click on the “New Project” button to create a new project. Give your project a name and description and choose the type of application you’ll be testing (e.g., web application, mobile application). Click on “Create” to proceed after this step.

➕ Recording a Test: Once your project is set up, you can start recording tests. Click on the “Record” button to launch the recorder.

TestCraft will open a browser window where you can navigate to your application under test. Perform the actions you want to automate, such as clicking buttons, filling out forms, or navigating through pages. TestCraft will automatically capture your actions and generate test steps based on your interactions.

➕ Test Steps Enhancements: After recording, you can enhance and modify the test steps as needed. Add validations to verify expected outcomes, such as checking for the presence of elements or verifying text.

Include conditions and loops to handle dynamic elements or repetitive tasks. Customize test data inputs for parameterized testing.

➕ Test Execution: Once your test is ready, you can run it to validate your application by clicking on the “Run” button. TestCraft will launch the test in a test environment and execute each step sequentially.

You can monitor the test execution progress and view detailed logs and reports.

Leapwork

On the other hand, creating and executing tests in Leapwork involves a visual modeling approach where users design automation flows using a flowchart-like interface. Below are the steps to create and execute a test in Leapwork:

➕ Create a New Flow: Install Leapwork application in your computer and open it. Click on the “New Flow” button or navigate to File > New Flow to create a new automation flow.

➕ Add Actions: Within the flow canvas, you’ll see various actions available in Leapwork’s library on the left side. Drag and drop actions onto the canvas to create your automation flow. Actions could include opening a web browser, navigating to a URL, clicking on elements, entering text, verifying text, waiting for elements, etc.

➕ Configure and Connect Actions: Double-click on each action to configure its properties. For example, if you add an “Open Browser” action, you’ll need to specify the browser type and URL to open. Connect actions together to define the flow of your automation. After that click and drag from one action’s output port to another action’s input port to create connections.

➕ Add Validation: Include validation steps to verify that your application behaves as expected. Use validation actions such as “Verify Text” or “Verify Element Exists” to ensure the correct behavior of the application.

➕ Run the Test: Once your automation flow is created, click on the “Run” button to execute the test. Leapwork will execute each action in the flow sequentially, performing the defined interactions and validations.

➕ Review Results: After the test execution is complete, review the test results in Leapwork’s dashboard. If any issues or failures are identified during the test execution, analyze the logs and debug the automation flow as needed.

Comparisons

Here is the quick comparison between the two tools to understand which one is more useful under what kind of scenario.

➕ Primary Focus:

TestCraft: Primarily focused on web application testing.

Leapwork: Offers automation across web, desktop, virtualized, and Citrix environments.

➕ Additional Capabilities:

TestCraft: Focuses solely on test automation.

Leapwork: Supports both test automation and robotic process automation (RPA) tasks, such as data entry and form filling.

➕ Supported Environments:

TestCraft: Primarily supports web applications.

Leapwork: Supports automation across web, desktop, virtualized, and Citrix environments.

➕ Deployment Model:

TestCraft: Cloud-based deployment model.

Leapwork: Offers both cloud-based and on-premises deployment options.

➕ Ease of Use:

TestCraft: Emphasizes ease of use and accessibility for testers with varying levels of technical expertise.

Leapwork: Offers a user-friendly visual modeling approach, suitable for testers and automation specialists.

➕ Community and Support:

TestCraft: Provides community forums, documentation, and customer support channels.

Leapwork: Offers extensive documentation, training resources, and customer support services.

➕ Pricing Model:

TestCraft: Pricing based on subscription plans with varying features and usage limits.

Leapwork: Offers flexible pricing options based on the number of licenses and deployment model.

➕ Integration Ecosystem:

TestCraft: Integrates with popular CI/CD tools and issue tracking systems.

Leapwork: Offers integrations with a wide range of third-party tools and systems for seamless automation workflows.

Conclusion

Choosing between TestCraft and Leapwork depends on factors such as the specific requirements of the automation projects, the complexity of your applications, and the skillset of your testing team. TestCraft excels in simplicity, ease of use, and collaboration, making it suitable for testers with varying levels of technical expertise. On the other hand, Leapwork’s comprehensive automation capabilities, visual modeling approach, and support for diverse environments make it ideal for organizations with complex testing requirements and multi-channel applications.

If you want to read more on codeless test automation, please see my article on it — Codeless Test Automation

If you liked my story, you could clap to help this reach more people and follow my profile @ Kaustav Singha Roy

Feature flags are implemented to control the release of features in a more controlled and gradual manner particularly when specific features need to be compared against each other or acceptability of certain feature needs to be understood. This is a good approach to test in production while doing continuous delivery, enabling gradual rollouts and rollback option, if required.

A/B testing on the other hand is a technique that is very useful for user experience research. By providing two alternatives to same or different sets of users, we can research on their response and understand user acceptance pattern based on which a decision on the correct solution can be made. Pretty much all kinds of features in a consumer tech product can be available various options in terms of text, colour, image, design etc and feature flags often make it easy to make these choices in a user driven way.

Feature flags, with their easy rollback options and comparative feature, are very suitable tools to perform A/B testing in any product. Here we are going to see how to configure feature flags in popular CI/CD tools, perform A/B testing and make decisions.

➕Deployment Tool: I am considering one of the more popular CI/CD tools- Jenkins. Jenkins provides a framework for building, testing, and deploying applications but does not include specific features for managing and controlling feature flags. Since Jenkins itself does not come with built-in native support for feature flags, we will have to integrate with another tool that specialises on Feature Flags. The integrated services will allow us to control feature releases, target specific user segments, and manage feature configurations.

➕Feature Flag Tool: There are various popular tools in the market for Feature Flags like LaunchDarkly, Split.io, Rollout.io, Unleash, Toggles etc. As you can see from the name itself, all of them specialize in splitting, optimizing and rolling out features with a toggle facility. For the example here I am choosing LaunchDarkly.

➕The Use Case: There is a simple UI where users can select on option out of multiple alternatives and proceed to next page. The options are presented in two ways:

A) A radio button showing 4 alternatives

B) A dropdown showing the same alternatives

The goal is to understand which is a better UI design from the user behavior. We want to release the features to two different sets of users and understand their behavior.

➕Set Up LaunchDarkly: Create a LaunchDarkly account and proceed to create the Feature Flag. There are various types of feature flag options available based on how we want to use it.

For the use case, I chose ‘Experiment’ type and created the Feature Flag. Feature Flag key is ‘dropdown-or-radio’ which will be required later for configuration.

Once the flag is created, the next step is to define target population for the alternatives. This can be done based on various segment definitions, specific individuals, system definitions or by building customized population rules. This will determine which target population will be used for A/B testing depending on the feature flag toggle.

The feature flag set up in LaunchDarkly is now complete.

➕Install and Configure LaunchDarkly: The next steps are to intall and configure LaunchDarkly using the following steps.

• Add the LaunchDarkly SDK to your application code. This may involve adding dependencies to your project. Example for Java with LaunchDarkly Java SDK:

<dependency>
    <groupId>com.launchdarkly.client</groupId>
    <artifactId>launchdarkly-client</artifactId>
    <version>6.2.0</version> 
</dependency>

• Initialize the LaunchDarkly SDK with your SDK key after obtaining it from LaunchDarkly account. This is typically done at the start of your application.

import com.launchdarkly.client.LDConfig;
import com.launchdarkly.client.LDUser;
import com.launchdarkly.client.LDClient;

public class YourApplication {
    public static void main(String[] args) {
        // Replace "YOUR_SDK_KEY" with your actual LaunchDarkly SDK key
        String sdkKey = "YOUR_SDK_KEY";

        LDConfig ldConfig = new LDConfig.Builder()
            .apiKey(sdkKey)
            .build();
       
        LDClient ldClient = new LDClient(ldConfig);

       boolean isFeatureEnabled = ldClient.boolVariation(
                  "dropdown-or-radio",new LDUser("user-key"), false);
       //user-key here is the user(s) engaged to perform the A/B testing
    }
}

Use the feature flag value in your application logic like below to configure it in coding:

        if (isFeatureEnabled) {
            System.out.println("Feature A is enabled");
            //show dropdown UI
        } else {
            System.out.println("Feature B is enabled");
           //show radio UI
        }

➕Configure with Jenkins: Configure Jenkins to integrate with LaunchDarkly. This might involve setting up environment variables for your LaunchDarkly SDK key.

pipeline {
    environment {
        LD_SDK_KEY = credentials('launchdarkly-sdk-key')
    }
   
}

Once we run the Jenkins pipeline, it will execute the defined stages. The LaunchDarkly feature flag evaluation stage will determine whether the feature is enabled or disabled for the specified user, allowing you to conditionally deploy your Java application based on the feature flag state.

➕Run A/B Testing and Analyse: LaunchDarkly’s dashboard has an ‘Insight’ tab which will show results of both testing, allowing us to compare various metrics. For this example, we can have a simple metric of click through rate based on what percentage of users chose to go to the next page in case of both options A and B. Depending on the results, we can iterate on various population groups, adjust testing parameters and refine the application by making an informed decision on preferred user experience.

Conclusion

All of the available Feature Flag tools in the market offer various customization to use Feature Flags in the code. Apart from the A/B testing explained here, Feature Flags offer quick roll back option to risky features and added benefits during release process. These are easily configurable with existing CI/CD tools and can make the CI/CD pipeline even more robust and feature rich helping in seamless delivery and stable products.

If you liked my story, you could clap to help this reach more people and follow my profile @ Kaustav Singha Roy

How to Configure and Use Feature Flags for A/B Testing was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

The software development industry is changing quite rapidly. Software quality assurance, which is an integral part of the software development life cycle, is no exception. QA plays an important role in ensuring the reliability, functionality and end user satisfaction of modern applications. Over time what used to be manual testing has evolved into automated testing which involves writing code to execute repetitive testing steps and generate test outputs automatically. Typically, most projects today would have a hybrid approach having a mix of both automated and manual testing.

In addition to requiring specialized programming skills, automated testing also require time and effort which can sometimes exceed the benefits of automation.

This problem brings into picture codeless test automation, which enables non-technical testers to participate actively in the QA process. In addition, there is a jump in productivity owing to lack of coding effort which has a huge financial benefit in itself.

This is a look into various aspects of codeless test automation and some of the products available today.

Why to Use Codeless Test Automation

The answer to this should be simple and intuitive. There is usually a simple graphical user interfaces (GUI) to design and automate tests. The testers would drag and drop components and the coding takes place dynamically in the background without the tester having to provide any input. There is no need for dedicated automation engineers and testers can focus more on test design and analysis and not on the coding.

In some cases non-technical resources like business analysts could be involved in the functional testing phase. They may have good subject matter expertise but not advanced technical skills to write automated tests effortlessly. Codeless test automation is easy for them to adapt to as well. Even for experienced automated testers this is undoubtedly a much faster process to create tests.

In addition to that, there is a reduction in maintenance headache often as there is no automated testing codebase that needs frequent update.

Having market standard products brings in another important benefit. Normally they are well researched and exhaustive and increases the usual test coverage which may not factor in all aspects. Codeless test automation tools often provide a wide range of pre-built test libraries and integrations with various technologies and platforms. Testers can leverage these resources to create comprehensive test suites, covering different aspects of the application, such as UI interactions, data validation, and API testing. This helps identify potential issues across multiple layers of the software stack which may take significant effort and man power to accomplish otherwise.

How does it work

For anyone attempting to try this, these steps can be followed:

➕ Platform Selection : Research and choose a codeless test automation tool or platform that suits your project requirements. There are several popular options available in the market, such as TestCraft, TestProject, Katalon Studio Tricentis Tosca etc.

➕ Visual Scripting: Utilize the graphical user interface (GUI) provided by the codeless automation platforms to design test cases. There could be drag and drop components, predefined actions, visual workflows that create test scenarios.

Arrange the test steps in the desired sequence and configure inputs, test conditions and desired output.

➕ Test Data Configuration: Set up the necessary test data required for executing the test cases. Define input values, mock data or connect to external data sources. Some codeless test automation tools provide built-in data management capabilities to streamline this process.

➕ Execute Test Cases: Execute the designed test cases using the codeless test automation platform.

➕ Analyze Test Results: Once the test execution is complete, review the test results and analyze any failures or discrepancies.

Codeless test automation platforms provide comprehensive test reports and logs, highlighting the status of each test case and any encountered issues. This also reduces the manual effort required otherwise.

Challenges

Obviously like anything else, this also comes with its own challenges which needs to be kept in mind.

➕ Limited Customization: Ultimately codeless aspect is achieved by standardising test flows and proving pre-built tools to achieve standard automation. This also means they may have limitations when it comes to customizing complex test scenarios. Advanced test cases requiring intricate logic or conditional branching may still require some level of coding or the assistance of a technical developer.

➕ Learning Curve: Although codeless test automation aims to bridge the gap between technical and non-technical testers, there is still a learning curve associated with mastering these tools. Testers need to familiarize themselves with the specific interface, workflows, and concepts of the chosen codeless automation platform. So the actual benefit may be realized only after a period of time.

➕ Along with that the usual challenges of integrating any software product remain here too. Organizations need to evaluate codeless test automation solutions that align with their development ecosystem and ensure there is no conflict with existing architecture. Not all products will work everywhere.

Lastly some of the existing products in the areas include TestCraft, TestProject, Katalon Studio and Tricentis Tosca. Almost all of them typically provide a visual drag and drop interface along with test recorder and object spy for effortless test creation. They provide almost all of the benefits explained above. In addition, some of them provide cloud based test execution and integrates with CI/CD tools as well enabling a smooth DevOps workflow supporting market leading products in these spaces.

Overall this is an exciting and highly productive aspect to think about for any project team having time and budget constraints. However, it’s important to consider the specific requirements and constraints of the project when evaluating these products all of which can help in reducing coding overhead for test automation.

If you liked my story, you can clap to help this reach more people and follow my profile @ Kaustav Singha Roy

The technology industry is evolving rapidly, necessitating agility and efficiency in development processes. Agile and Kanban practices have become instrumental in maintaining quality while accelerating delivery. A key paradigm shift in testing and QA approaches is the adoption of “Shift-Left” testing. This article explores the significance of Shift-Left testing, its divergence from traditional methods, the associated benefits and common applications.

Difference with Traditional Testing: In traditional testing, the testing phase is positioned towards the “Right” of the software development life cycle (SDLC). This means that requirement understanding, test case creation, execution, and defect detection occur after development is complete. This approach poses risks, such as delays and missed project timelines due to late bug detection and increased rework. To address these issues, the Shift-Left approach moves many testing steps to earlier phases of the project. It promotes collaboration between developers and testers, fostering shared responsibility for quality.

How Shift-Left Helps:

1. Early Bug Detection: By testing early, Shift-Left testing catches defects in their early stages, reducing the risk of critical issues going unnoticed. This minimizes the cost and effort required for defect fixing, avoiding setbacks.
2. Improved Communication and Collaboration: Continuous feedback from testers enhances code quality and increases efficiency. Testers gain a clear understanding of requirements from the beginning, resulting in better collaboration.
3. Faster Time to Market: Shift-Left testing accelerates the development cycle by reducing rework, optimizing test cycles, and streamlining defect resolution. This enables organizations to gain a competitive edge by delivering software solutions faster.
4. Test Driven Development (TDD): The Shift-Left approach aligns well with Agile continuous testing and TDD methodologies. Features are tested from the initial draft code and continuously throughout the development process. By the time formal testing begins, a significant portion of the testing steps has already been completed, reducing inefficiencies.

In a Shift-Left approach, testing activities are not delayed until a dedicated testing phase. Instead, they occur concurrently with development. The following steps exemplify this approach:

• Requirements understanding from testers’ perspective
• Test planning
• Test design
• Test environment setup
• Code quality reviews
• Partial test execution
• Early defect identification and management

Types of Testing In-Scope

While not all testing types can be executed before development is complete, the following can be shifted at least partially to the left.

• Unit Testing: In Scope. Developers conduct unit testing during development once logical functionalities are complete.
• Integration Testing: In Scope. Testers can test the integration between various modules early and continuously.
• Regression Testing: In Scope. If regression test cases are automated, they can be executed during development, providing early feedback. Manual testing may have limited success in shifting regression testing to the left.
• Performance Testing: Partially in-scope. Proper performance testing requires complete deployment, making early results less accurate and beneficial.
• System Testing: Partially in-scope. By definition, system testing involves testing the software as a whole and is typically executed after development completion. However, preparatory steps, such as test creation, can occur earlier.
• Security Testing: Partially in-scope. Similar to performance testing, comprehensive security testing is advisable after development completion.

Implementing the Shift-Left approach requires a cultural shift and additional training for testers. Despite the challenges, it offers significant advantages to Agile teams and organizations requiring rapid development and testing. While the concept of Shift-Left testing has existed for some time, it has gained additional traction in recent years, helping organizations stay competitive in the ever-evolving software development landscape.

If you liked my story, you can clap to help this reach more people and follow my profile @ Kaustav Singha Roy

Code smells are problems with codes which can later snowball into tricky bugs and maintainability of the code even if they may not create a problem now. The code may be working fine and continue to work fine for years to come. But there could be various factors which require more effort than usual to make simple changes. New programmers replacing old team may find it difficult to understand the code and sometimes performance issues can come in due to badly written code as well eventually increasing potential technical debt of the code.

From an identification perspective, there are off the shelf products like Sonarqube in the market that can be easily installed and configured to capture code smells. We are going to investigate some of the common code smells and see how they can be easily fixed.

1. Code Duplication

Copying and pasting existing code is nothing new. You may google and find useful and tested code that solves your problem without much headache. If the solution happens to be already in the existing code repository, even better. If the same steps need to be performed and there is a code block already tested and in production, what can go wrong if you copy and reuse again?

Why is this a problem?

So over a period of time you can have dozens of code blocks copied and pasted and spread all over the code base. What happens some change needs to happen in the block of copied code? The person doing will have to check entire repository and make the same change everywhere manually. This impacts maintenance cost of the project and larger the project, more amplified the problem will be.

Imagine legacy projects of various sizes and typically 10,000 lines of code maintained by one developer. Lets consider 20% code smell which means that much code is actually copied and pasted everywhere.

As we can see, the problem is significantly magnified for large projects. As duplicate lines of code increases from 2,000 to 2 million, about 200 developers are required to individually go through the common blocks and ensure all changes are duplicated again. What happens if someone forgets all the places this code is duplicated? This would potentially introduce to many defects across the code and will be so costly to fix.

The DRY principle suggests creating common methods/functions and calling that by passing appropriate parameters instead of copy pasting code. The common repository can easily be maintained by much smaller number of developers instead of the large numbers in the table above. This ensures any change is replicated everywhere without the need to manually copy and paste again.

For example, instead of having 200 developers maintaining duplicate codes in a 10 Million lines repository, may be even 10 developers can maintain common blocks of code that are reused everywhere. Add to this amount of testing effort required to test all the blocks separately instead of just the common function. requiring large number of testers. Solving this results in huge cost savings and directly reducing technical debt cost.

2. Hard coding/Magic Numbers

The second biggest type of code smell problem is hard coding of parameters. Its very easy to directly assign some numerical or text values to a variable and often that happens without any associated explanation. This is lucrative to any developer who is in a hurry to solve a problem without finding a more generic solution.

This kind of code smell is sometimes known as magic numbers as well when hard coding exists without even any explanation and some numbers are randomly used directly in a statement.

Why is this a problem?

Lets see a typical example of magic numbers and hard coding without any explanation.

What if someone else starts to use the same code. This would reduce lack of understanding and waste a lot of time which could have been avoided.

Hard coding and magic numbers also create problem from the DRY perspective. There is no single point of control and every time some change happens in the numbers, you have to check all hard coding separately and make changes. This should be resolved by introducing a variable that is easily understandable and assign magic numbers there as a single point of control.

Below is an example where we are calculating energy from mass and speed of light. The constant comes out of nowhere and without any explanation and if this equation wasn’t so famous, it would be difficult for anyone to understand what we are doing here.

def energy(mass:float)-> float:
 return mass*300,000,000**2

We are solving this by introducing the variable with correct naming convention which increases maintainability and readability as well.

speed_of_light = 300,000,000
def energy(mass:float)-> float:
 return mass*speed_of_light**2

There is another issue which is security related. Look at the below code where user credentials have been hardcoded directly. This kind of code is quite easy to hack into by a skilled hacker and increases security concern of the entire codebase.

def user_login():
 userid = 'user123'
 password = 'password'

3. Comments Density

The third most important code quality related issue to track would be comments coverage. In simple words, this means how much comments are there in the code for each line of code. This is typically measured through comments density.

Comments Density = comment lines*100/(comment lines + code lines)

A 50% comment density here would mean there is one comment line for each line of code.

Why is this important

The obvious answer is readability and maintainability. The idea is not to have comments explaining every line of code but to have enough comment density that makes the code easily readable and understandable for a new developer into the project. Even for existing developers who may forget the purpose of an existing piece of complex code, debugging becomes much easier with a well constructed comments coverage.

Large projects can solve this problem by setting up a comments density standard that needs to be maintained at each file level or project level. A good practice would be to have a comment density of at least 20% which basically means 1 comment line for every 4 lines of code at least.

Conclusion

To sum it up, having a good strategy to avoid all three code smells mentioned above has direct impact on security, cost, readability, maintainability of a project. If left unchecked, these can produce serious defects in the project which again becomes difficult to solve for the same reasons. Defects also raise cost of technical debt of the project which can curtail a project’s ability to add new features. This is like a dormant volcano which creates little issue for a long period of time and then can suddenly explode into something serious. Organizations and project teams should invest from the start to avoid this scenario.

If you liked my story, you can clap to help this reach more people and follow my profile @ Kaustav Singha Roy

The 3 Major Code Smells and How to Avoid Them was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Navigating the landscape of web automation and testing tools can be a challenging exercise. In recent years, Puppeteer has held the spotlight as the go-to solution for many developers since its introduction in 2017, thanks to its robust features and user-friendly approach. However, there’s a new contender stepping into the arena: Playwright. Developed by Microsoft, Playwright aims to simplify browser automation and provide a more comprehensive solution for various testing scenarios.

In this article, I will compare Playwright and Puppeteer, highlighting their similarities, differences, strengths, and weaknesses. The goal is to equip you with the essential insights to make an informed decision on which tool best aligns with your project requirements and development needs.

Overview of Playwright and Puppeteer

If you are looking to understand Playwright in detail, please see my article on it — Playwright . To summarize, Playwright is an open-source Node.js library developed by Microsoft that enables developers to automate browser actions and interactions for testing and scraping purposes. It supports multiple browser engines, including Chromium, Firefox and WebKit, allowing for seamless cross-browser testing. Playwright provides an easy-to-use API and a robust set of features, making it a go-to choice for many developers.

On the other hand, Puppeteer is a Node.js library created by the Chrome team at Google. Like Playwright, Puppeteer is designed for automating browser actions and interactions, but it primarily focuses on the Chromium browser engine. Puppeteer boasts a user-friendly API and a strong feature set, making it a popular choice for web automation and testing tasks since the time it came out in 2017.

Similarities

Playwright is written and maintained by people who had earlier worked in Puppeteer and then moved to Microsoft so there are obvious similarities.

Both tools provide a comprehensive API for automating browser interactions, such as clicking buttons, filling out forms, and navigating pages. There is also headless browser support, allowing developers to run tests and automate tasks without the need for a visible browser window. Both tools can capture screenshots of web pages or generate PDF files, making it easy to save visual representations of a site’s content. In both Puppeteer and Playwright, developers can intercept and modify network requests and responses, providing greater control over the testing environment. Both allow execution of JavaScript within the context of the web page as well, enabling developers to interact with and modify the DOM as needed.

Differences Between Playwright and Puppeteer

Despite their obvious similarities and similar goals, Playwright and Puppeteer have some key differences that set them apart:

Browser Support: One of the most significant differences between the two tools is their browser support. Playwright provides out-of-the-box support for Chromium, Firefox, and WebKit, facilitating cross-browser testing. In contrast, Puppeteer primarily focuses on the Chromium browser engine, with limited support for Firefox and no native support for WebKit.

Selector Engine: Playwright offers a more advanced selector engine compared to Puppeteer. It supports a variety of selector types, including CSS, XPath, and text-based selectors, while Puppeteer mainly relies on CSS and XPath selectors. This can make it easier to target specific elements on a web page with Playwright.

Multiple Contexts and Pages: Playwright allows developers to work with multiple browser contexts and pages simultaneously, enabling more complex testing scenarios. Puppeteer, on the other hand, has limited support for managing multiple contexts and pages, making it more challenging to handle intricate test cases.

Auto-Waiting Mechanism: Playwright features an advanced auto-waiting mechanism that automatically waits for elements to become available before performing actions. This can help to reduce the need for manual timeouts and improve the stability of tests. Puppeteer lacks this advanced auto-waiting functionality, requiring developers to rely more on manual timeouts and workarounds.

Accessibility Testing: Playwright has built-in support for accessibility testing, allowing developers to verify that their web applications meet accessibility standards. Puppeteer does not have native support for accessibility testing, requiring additional tools or libraries to perform such tests.

When to select Playwright:

➕ You need to test across multiple browsers, as Playwright offers out-of-the-box support for Chromium, Firefox, and WebKit.
➕ You have complex testing scenarios that involve multiple browser contexts or pages, which Playwright handles more effectively.
➕ You prefer advanced element selection capabilities, as Playwright provides a versatile selector engine.
➕ You value stability and automatic waiting mechanisms, which are built into Playwright and help reduce flakiness in tests.
➕ Accessibility testing is a priority, as Playwright offers built-in support for this feature.

When to Choose Puppeteer:

Puppeteer might be the better solution if:

➕ You mainly target the Chromium browser engine and don’t require extensive cross-browser testing.
➕ You or your team have prior experience with Puppeteer or an existing codebase that leverages it, making it more efficient to continue using the tool.
➕ You have simpler test cases that don’t require managing multiple browser contexts or pages, which Puppeteer handles with some limitations.
➕ Your project relies on Chrome-specific features or APIs, as Puppeteer’s close integration with the Chromium browser engine ensures better compatibility and support.

Happy testing!

If you liked my story, you can clap(50) to help this reach more people and follow my profile @ Kaustav Singha Roy

Web application development has come a long way since its inception and with it the need for robust testing tools is also greater than ever. Continuous testing is also of paramount importance with the advent of CI/CD pipelines. Enter Playwright, a powerful and versatile end-to-end testing framework that allows you to write tests for web applications with ease. So when can we choose Playwright over other so many continuous testing tools and how to use it?

There are distinct advantages of using Playwright over other tools like Puppeteer, Selenium, Cypress etc particularly under following circumstances.

· Cross-browser testing is a priority: If your application needs to work seamlessly across different browsers, Playwright’s cross-browser support can be a game-changer. Other tools, like Puppeteer, only support Chromium-based browsers, which might not meet your testing requirements.

· Modern web technologies: If your application leverages modern web features like single-page applications (SPAs), web components, or progressive web apps (PWAs), Playwright’s support for modern JavaScript syntax and advanced automation capabilities can be used for thorough testing.

· Comprehensive testing solution: If you’re looking for a single tool that can handle end-to-end testing, integration testing, and even visual testing, Playwright is an excellent choice. Other tools might require additional libraries or integrations to achieve the same level of functionality.

· Multiple environments: Playwright’s ability to run tests in headless and non-headless modes, as well as its support for various platforms (Windows, macOS, and Linux), makes it a versatile choice for teams working in diverse environments.

Installing Playwright

First things first, let’s get Playwright up and running on your machine. To install it, simply open up your terminal and run the following command:

npm install — save-dev playwright

This will add Playwright as a development dependency to your project. If you’re using yarn, the command would be:

yarn add — dev playwright

Configuring Playwright

With Playwright installed, it’s time to set up a basic configuration. Create a new file called playwright.config.js in your project’s root directory and add the following content:

module.exports = {

launchOptions: {

headless: true,

},

browsers: [“chromium”, “firefox”, “webkit”],

};

This configuration tells Playwright to run tests in headless mode (without displaying a browser UI) and specifies the browsers you’d like to test your application against. You can customize these options as needed for your project.

Using Playwright

To start using Playwright, create a test file (e.g., kaustav.test.js) and import the necessary modules:

const { test, expect } = require(“@playwright/test”);

Now you can write your first test! Here’s an example that navigates to a webpage and checks for a specific heading:

test(“Check the heading on the homepage”, async ({ page }) => {

await page.goto(“https://kaustavsingha.com");

const heading = await page.textContent(“h1”);

expect(heading).toBe(“Welcome to the Kaustav Singha Roy’s Website”);

});

To run the test, use the following command in your terminal:

npx playwright test

What to Keep in Mind

Handle asynchronous operations: Playwright is built around async/await, so ensure you handle promises and async functions correctly to avoid flakiness and unexpected behaviour in your tests.

Optimize for speed: Running tests in parallel and using the — workers flag can significantly speed up test execution. But be mindful of resource usage and try to strike a balance between speed and system resources.

Embrace Playwright’s features: Playwright offers a variety of built-in tools, such as network interception, device emulation etc. This is one of the advantages of this tool over some others where additional packages need to be installed so use it well.

Playwright is a great addition for web developers seeking a powerful and flexible end-to-end testing solution and has definite advantages over existing automation tools. However, the choice as always needs to be situation based and keeping in mind the entire use case and tech stack of the project. Happy testing!

When and How to Use Playwright was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many of us struggle to understand the different philosophies of development. There are quite a few ways to develop software in the market today. As a testing professional this is important for me so this is my take from my experience on this topic.

Test Driven Development (TDD)

This is perhaps the oldest of the method here and was developed in the late 1990s.

Unit Testing is the driving force here. Rather than writing the code and then testing, first it is tested. This will obviously fail and then code will be written and tested again. This process will keep repeating till the test is successful.

Test cases are typically automated in same language as the implementation language.

The steps involve –

· Writing unit test cases in collaboration between developers and testers

· Executing test cases

· Coding to address issues

· Executing test cases again and so on..

· Testers can do integration tests once Unit test is successful.

Behavior Driven Development (BDD)

This method started getting popular in the early 2000s and acceptance testing is the focus here. This is driven from the purpose of focussing on the expected behavior so that both technical and non-technical people are on the same ground. Typically implemented using many available tools in the market like Cucumber, Quantum, SpecFlow, JBehave etc.

Typically the test cases would be written in a language called Gherkin which follows a Given, When, Then format of specifying anything. Tests are written at scenario level and clearly maintained in feature files.

The end goal is to have a test case in natural language yet in a standard format. This can be understood and implemented by everyone working in the team and ensures end goal is met.

The steps involve -

· Identify the scenario for BDD

· Write the feature file in Given, When, Then format

· Run the feature file in appropriate language

· Check the test results of the run and fix the errors.

· Redo the process

Acceptance Test Driven Development (ATDD)

This also came into focus in the early 2000s. Acceptance testing is again the focus here as the name suggests but the purpose is clear capture of the requirements. This is also usually written in Gherkin and typically the tools used in BDD can be used here also. This brings customers to the testing table even before development has begun.

There are few situations where ATDD can do wonders. As the end goal is very clear to everyone, estimate are more accurate and collaboration improves in the team. It can help when technical debt is high in the project.

ATDD can be effective in reducing rework also due to clarity and save time. It reduces many problems Agile teams typically face.

The steps involve –

· Train the stakeholders on objectives and expectations

· Write the acceptance test cases

· Implement iterative learning

Domain Driven Development (DDD)

Understand the big picture and end goal. Once that is clear, decompose it into smaller deliveries and follow usual SDLC for the smaller pieces. This is the gist of domain driven development which came after all the other methods. This is not replacing any of the above methods but working in tandem with them to improve the process.

Summary

So do these methods exist separately? Is it a choice to pick one of them or all together?

It depends on the project but for a reasonably big one, all of them can be used together. In fact for best results, it may be good to combine some of them together and not just pick one.

· Start with the big picture by doing DDD

· Once decomposed into smaller pieces, go with BDD or ATDD or both as required

· Once further decomposed into unit level, developers need to work with TDD

There may be training period for the team to get accustomed to this but once there, the development process can improve and reduce issues as well.

If you liked my story, you can clap(50) to help this reach more people and follow my profile @ Kaustav Singha Roy