CODE QUALITY 

YOU CARE ABOUT CODE QUALITY

BUILD A CODE QUALITY ASSURANCE SYSTEM FOR YOUR TEAM

1. VERSION CONTROL TOOL TO ENSURE CODE QUALITY AND TRANSPARENCY

2. STYLE GUIDE FOR READABLE AND COMPREHENSIBLE CODE

Use linters to automatically test code style

 Very Large-Scale Development

Boehm and Turner (2003) suggested that programmes should find a Bsweet spot combining a
mixture of traditional and agile methods.

 Previous research on the use of development methods suggests that methods need to be adapted to the work context (Fitzgerald et al. 2006).

We first describe some of the main differences between traditional and agile development before
focusing on three aspects of adaptation that are critical in very large scale development: customer involvement, software architecture, and inter-team coordination.

 Traditional and Agile Development

Nerur et al. (2005) described the fundamental assumption behind traditional methods to be that
information systems are fully specifiable and built through meticulous and extensive planning.

Agile methods, on the other hand, assume that information systems can be built through
continuous design, improvement, and testing based on rapid feedback and change.

Learning and adaptation should be embraced (Conboy 2009). Adapting the method to the context will
involve balance in a number of areas (Vinekar et al. 2006), as illustrated in Table 1.

Very largescale projects involve great risk and management attention. Boehm and Turner (2003) argued that traditional and agile methods should be balanced when facing risk such as increases in
programme size.

The transition from traditional plan-driven development to a more agile method with iterations and development conducted in small teams was the focus of a study by Petersen and Wohlin (2010).

They examined the development of three large subsystem components in an Ericsson product involving 117 people and found that many of the issues raised in traditional development were not raised after the transition to agile development.

This suggests that agile methods can also work well in large-scale
product development.

Another study from Ericsson finds that agile principles in large scale contributed to knowledge sharing, and led to increased project visibility and effectiveness in coordination (Lagerberg et al. 2013).

One of the very few studies on large projects combining traditional and agile methods examined a project to develop a web-based customer booking engine for an American cruise company (Batra et al. 2010).

The study describes a $15 million project that lasted for 28 months.

The project was distributed and combined Scrum with the......

Table 1 Traditional versus agile development (excerpt from (Nerur et al. 2005))




Project Management Body of Knowledge3 framework. Customers were available but did not work together with developers on a daily basis. The iteration length was two weeks.

Some of the challenges identified in the study were due to the size and involvement of a high number of internal business sponsors, users, project managers, analysts, and external developers from the UK and India; Customer involvement.

 The communications were mainly formal, and formal documents were needed for changes. However, the project was considered a success, and the study describes the balance between traditional
and agile methods as essential in achieving both project control and agility.

A model organizing development as chains of Scrum teams (the output of one team
is the input of the next) is described in a study of three cases of organizations with 150,
34, and 5 Scrum teams (Vlietland and van Vliet 2015). The study investigated the strategy,
structure, collaboration, coordination, communication, mindset, and competence of
people.

The dependence of teams on the results from other teams introduces a number
of challenges.

The three cases illustrate challenges that include a lack of coordination in the chain, mismatch of backlog priority between teams, challenges in alignment between teams, and unpredictability in delivering on commitments, this suggests challenges with inter-team coordination and main design decisions as expressed in the software architecture.

Customer Involvement

Agile methods are people-centric and recognize the value that competent people and their relationships bring to software development (Nerur and Balijepally 2007).

A key pillar in an agile method is the close and continual collaboration between clients and
developers (Maiden and Jones 2010).

Therefore, agile methods are highly dependent on the on-site customer identifying and prioritizing features, providing feedback, and guiding change in the course of the development (Vinekar et al. 2006).

 In their study on a large-scale agile project, Bjarnason et al. (2012) found that low customer involvement in near-development roles in combination with weak awareness of overall goals
may result in unrealistically large project scope.

 Further, overscoping can lead to a number of negative effects, including quality issues, delays, and failure to meet customer expectations.

A study on large-scale and distributed projects found that understanding requirement dependencies is of paramount importance in such projects (Daneva et al. 2013).

Active participation and constant involvement of the customer in systems development yields greater benefits, but this reliance on the customer can fail if the on-site customer goals are misaligned with the goals of other stakeholders.

Having multiple on-site customers in a large-scale project increases the risk of failure because of the
challenge of establishing a common understanding among all customer representatives.

A fragmented view of the system that each customer may have is likely to have a negative impact on the project (Ramesh et al. 2010).

Further, when different stakeholder groups have different priorities, there is a need for open and transparent dialogue and cross-stakeholder group communication in large-scale agile projects
(Barney and Wohlin 2009).

 Software Architecture

The software architecture is the fundamental technical organization of a system.

 How and when to make architectural decisions have been the subject of major debate in the software
engineering field (Abrahamsson et al. 2010).

In traditional development, the architecture is defined prior to implementation and testing, whereas the architectural design emerges as a result of on-going clarification in ‘purist’ agile development.

Traditionally, software architecture is associated with up-front designs and stable structures that accommodate pre-defined, non-functional requirements.

The assumption is that the value of good architectural decisions will surface at a later point in time in forms such as more easily maintainable code and scalability (Faber 2010).

Also, sound architecture is largely invisible and provides an effective structure for subsequent functionality. It is interesting to note that software architecture has meaning and significance for a wide variety of stakeholders.

Different stakeholders are also likely to associate different meanings to software architecture.

Smolander (2002) suggested that the four metaphors blueprints, literature, language, and
decisions capture the meaning of software architecture for different actors involved in software
development.

This underlines the pervasive role of software architecture.

Several approaches to architecture work have been taken in large agile projects.

 Some start with the architecture (‘big up-front design‘) and then use agile methods.

 Others spend the first iteration focusing on architecture.

Others again start directly on the development and let the architecture emerge.

 To construct a large software system developed by a number of teams, it is vitally important for the architecture to be agreed upon and communicated without introducing the bureaucracy and overhead associated with traditional methods.

 In a study on software product companies, Unphon and Dittrich (2010) found that architectural knowledge was transferred by face-to-face communication with chief architects taking the role of a
By walking architecture.

Awareness and social protocols are important perspectives on how architecture is communicated.

 Unphon and Dittrich do not discuss the increased challenges of architectural work on a
large scale.

 In their study of a large-scale agile approach at Ericsson, Petersen, and Wohlin
(2010) found a need for a high-level architectural design to facilitate planning.

Nord et al. (2014) argued that for large-scale agile projects, agility is enabled by architecture, and
architecture is enabled by agility.

They suggested several tactics for handling architecture in large-scale projects, including making use of a matrix structure and focusing on the production infrastructure.

 Inter-Team Coordination

Coordination can be defined as Bthe managing of dependencies (Malone and Crowston
1994), where dependencies can be related to tasks, knowledge, resources, or technology.

The central challenge in coordination is identifying the right form or artifacts, arenas, and
the degree of formalization in large projects with high uncertainty.

 In small agile projects, the development team coordinates work through frequent informal interaction among themselves and with customers, as in the customer-on-site practice in eXtreme Programming.

 Scrum has dedicated meetings for planning, review, and retrospectives. Many teams use visual boards, like in Kanban, to show who is working on what and the status of work tasks.

Strode et al. (2012) explain coordination at the team level in agile teams and propose a model for
coordination strategy and coordination effectiveness.

For large-scale projects, there is less support. Scrum prescribes regular meetings between
Scrum teams (BScrum of Scrums) in order to manage the interfaces between teams.

Eckstein shows techniques that are applicable to large projects in order to facilitate planning, status
information, integration, and retrospectives in her book with recommendations to practitioners
(Eckstein 2004).

 Some large-scale agile frameworks have been suggested by practitioners (Larman and Vodde 2013; Larman and Vodde 2017; Leffingwell et al. 2017) that describe roles and arenas for inter-team coordination.

 Visual boards were the primary form of inter-team coordination in a project in Sweden described in an experience report by Kniberg (2011).

There is a small body of studies on inter-team coordination.

Vlietland and van Vliet (2015) propose that embedded coordination practices within and between Scrum teams positively impact delivery predictability in large projects.

 A study of BScrum of Scrums(Paasivaara et al. 2012) suggests that this forum did not lead to satisfactory coordination: feature-specific or site-specific fora were better, but coordination at the project level was still a challenge.

Researchers working closely with SAP (Scheerer et al. 2014; Scheerer and Kude 2014) have
developed models of coordination called B coordination configurations  and are exploring how
coordination configuration influences coordination effectiveness.

 Paasivaara and Lassenius (2014) describe a very large-scale development initiative at Ericsson with 40 teams where four types of communities of practice (Wenger 1998) are used to coordinate teams.

A survey on coordination in large-scale software teams found that respondents wished more effective and efficient communication, as well as the importance of good personal relationships for coordination (Begel et al. 2009).

A management science study (Ingvaldsen and Rolfsen 2012) suggests that inter-group
coordination is a major challenge when groups are self-managing.

Self-management involves giving teams the authority to decide how to 1) execute tasks, and 2) monitor and manage their work process (Hackman 1986).

 Moe et al. (2009) describe challenges to self-management at the team level and highlight challenges at the organizational level, such as shared resources, organizational control, and specialist culture

A Software Development Process for Small-Scale Embedded Systems

Developing software for small-scale embedded applications is different from developing large-scale software applications.

Large-scale applications use commercially available ‘one fits all’ software development solutions that are difficult to scale downward and usually miss the desired process goals.

In many cases, developing a small-scale software application development process within an existing corporate environment is quicker, less expensive, and results in superior developer productivity and product quality.


Figure 1: A selected group of use-case instances describe an iteration cycle in the implementation and test and verification phases of the development process.


Software pioneer Grady Booch famously commented that “Building quality software in a repeatable and predictive fashion is hard.”

This statement not only describes the difficulty of the software development process, but also describes the primary goal of any software development process — software products should be defect-free, maintainable, and have veracity requirements to guarantee a successful operation.

Software development processes can be fully described by four orthogonal views: methodology, process artifacts, process procedures, and quality assurance.

This article will focus on the methodology view.

ANALYSIS PHASE

Figure 2: Iterative development is use-case-driven; they are the information baseline source for all other documents.

DESIGN PHASE

Figure 3: The development phases are shown as UML swim lanes. Note that the maintenance phase uses the same process phases as the initial software development.

IMPLEMENTATION PHASE

TEST AND VERIFICATION (T&V) PHASE

MAINTENANCE PHASE

Build automation

In professional embedded software projects - especially in the industrial environment - we assume product life cycles of several years.

 Device families also "live" for decades, so a valid build and software management for board support packages over that time is essential to enable long-term, economic development.

At the same time, it makes the desired transparency and composability of open source software as well as the participation in innovations and continuous security updates from the community manager.

   
Flexible configuration and variant management

for embedded Linux Board Support Packages

At the latest, when Embedded Linux operating system software is subject to certification, you need to be able to prove a valid and reproducible build process with reliable version management.

The Build Management or Build Automation Management with appropriate software change management is usually on the one hand tooling and infrastructure, on the other hand, but also from defined processes.

Creating the software must also be independent of the configuration of a single (machine) computer and the expertise of a single developer.

Emlix has developed e2factory to meet these requirements as well as various projects subject to certification.

The software management and build system has been continuously maintained and developed since 2003 and is now used in several hundred development projects as well as maintenance and platform strategies.

e2factory is subject to GPLv3 and is freely available as a development tool.

With less stringent requirements for process safety over the life cycle and at the same time the necessity to provide an anonymous application developer with a suitable development environment, a reduced yocto approach with the Yocto construction system BitBake and the minimal distribution Poky-Tiny represents an alternative.

Build automation software

Not all the Java development is done through eclipse and not all the jars may be built from the command line ( or should be built from the command line).

You may need additionally run test cases, unit tests, and many, many other processes.

What ant does, provides a mechanism to automate all this work ( so you don't have to do it every time ) and perhaps you may invoke this ant script each day at 6 p.m.

For instance, in some projects, a daily build is needed, the following are the task that may be automated with ant, so they can run without human intervention.

• Connect to the subversion server.
• Download/update with the latest version
• Compile the application
• Run the test cases
• Pack the application ( in a jar, war, ear, or whatever )
• Commit this build binaries to subversion.
• Install the application in a remote server
• Restart the server
• Send an email with the summary of the job.

Of course for other projects this is overkill, but for some others is very helpful.

Java Build Tools: Ant vs Maven vs Gradle

In the beginning, there was Make as the only build tool available.

Later on, it was improved with GNU Make. However, since then our needs increased and, as a result, build tools evolved.

JVM ecosystem is dominated with three build tools:

🕶Apache Ant with Ivy
🕶Maven
🕶Gradle

🌞Ant with Ivy

Ant was the first among “modern” build tools. In many aspects, it is similar to Make.

It was released in 2000 and in a short period of time became the most popular build tool for Java projects.

It has a very low learning curve thus allowing anyone to start using it without any special preparation. It is based on procedural programming idea.

After its initial release, it was improved with the ability to accept plug-ins.

The major drawback was XML as the format to write build scripts. XML, being hierarchical in nature, is not a good fit for procedural programming approach Ant uses.

Another problem with Ant is that its XML tends to become unmanageably big when used with all but very small projects.

Later on, as dependency management over the network became a must, Ant adopted Apache Ivy.

The main benefit of Ant is its control of the build process.

🌞Maven

Maven was released in 2004.

Its goal was to improve upon some of the problems developers were facing when using Ant.

Maven continues using XML as the format to write build specification. However, the structure is diametrically different.


 While Ant requires developers to write all the commands that lead to the successful execution of some task, Maven relies on conventions and provides the available targets (goals) that can be invoked.


As the additional, and probably most important addition, Maven introduced the ability to download dependencies over the network (later on adopted by Ant through Ivy).

 That in itself revolutionized the way we deliver software.

However, Maven has its own problems.

 Dependencies management does not handle conflicts well between different versions of the same library (something Ivy is much better at).

XML as the build configuration format is strictly structured and highly standardized.

Customization of targets (goals) is hard. Since Maven is focused mostly on dependency management, complex, customized build scripts are actually harder to write in Maven than in Ant.

Maven configuration is written in XML continuous being big and cumbersome.

 On bigger projects, it can have hundreds of lines of code without actually doing anything “extraordinary”.

The main benefit of Maven is its life-cycle. As long as the project is based on certain standards, with Maven one can pass through the whole life cycle with relative ease.

 This comes at a cost of flexibility.

In the meantime, the interest for DSLs (Domain Specific Languages) continued increasing. The idea is to have languages designed to solve problems belonging to a specific domain. In the case of builds, one of the results of applying DSL is Gradle.

🌞Gradle

Gradle combines good parts of both tools and builds on top of them with DSL and other improvements.

 It has Ant’s power and flexibility with Maven’s life-cycle and ease of use.

An end result is a tool that was released in 2012 and gained a lot of attention in a short period of time.

For example, Google adopted Gradle as the default build tool for the Android OS.



Gradle does not use XML.

Instead, it had its own DSL based on Groovy
(one of JVM languages).


As a result, Gradle build scripts tend to be much shorter and clearer than those written for Ant or Maven.

The amount of boilerplate code is much smaller with Gradle since its DSL is designed to solve a specific problem: move software through its life cycle, from compilation through static analysis and testing until packaging and deployment.

Initially, Gradle used Apache Ivy for its dependency management. Later own it moved to its own native dependency resolution engine.

Gradle effort can be summed as “convention is good and so is flexibility”.

🌻Code examples

We’ll create build scripts that will compile, perform static analysis, run unit tests and, finally, create JAR files.

 We’ll do those operations in all three frameworks (Ant, Maven, and Gradle) and compare the syntax.

By comparing the code for each task we’ll be able to get a better understanding of the differences and make an informed decision regarding the choice of the build tool.

First things first. If you’ll do the examples from this article by yourself, you’ll need Ant, Ivy, Maven, and Gradle installed. Please follow installation instructions provided by makers of those tools.

 You can choose not to run examples by yourself and skip the installation altogether.

 Code snippets should be enough to give you the basic idea of how each of the tools works.

Code repository https://github.com/vfarcic/JavaBuildTools contains the java code (two simple classes with corresponding tests), check style configuration and Ant, Ivy, Maven, and Gradle configuration files.

Let’s start with Ant and Ivy.

❤Ant with Ivy

Ivy dependencies need to be specified in the ivy.xml file.

Our example is fairly simple and requires only JUnit and Hamcrest dependencies.

[ivy.xml]
<ivy-module version="2.0">
    <info organisation="org.apache" module="java-build-tools"/>
    <dependencies>
        <dependency org="junit" name="junit" rev="4.11"/>
        <dependency org="org.hamcrest" name="hamcrest-all" rev="1.3"/>
    </dependencies>
</ivy-module>


Now we’ll create our Ant build script. Its task will be only to compile a JAR file. The end result is the following build.xml.

<project xmlns:ivy="antlib:org.apache.ivy.ant" name="java-build-tools" default="jar">

    <property name="src.dir" value="src"/>
    <property name="build.dir" value="build"/>
    <property name="classes.dir" value="${build.dir}/classes"/>
    <property name="jar.dir" value="${build.dir}/jar"/>
    <property name="lib.dir" value="lib" />
    <path id="lib.path.id">
        <fileset dir="${lib.dir}" />
    </path>

    <target name="resolve">
        <ivy:retrieve />
    </target>

    <target name="clean">
        <delete dir="${build.dir}"/>
    </target>

    <target name="compile" depends="resolve">
        <mkdir dir="${classes.dir}"/>
        <javac srcdir="${src.dir}" destdir="${classes.dir}" classpathref="lib.path.id"/>
    </target>

    <target name="jar" depends="compile">
        <mkdir dir="${jar.dir}"/>
        <jar destfile="${jar.dir}/${ant.project.name}.jar" basedir="${classes.dir}"/>
    </target>

</project>

First, we specify several properties. From there on it is one task after another. We use Ivy to resolve dependencies, clean, compile and, finally, create the JAR file. That is quite a lot of configuration for a task that almost every Java project needs to perform.

To run the Ant task that creates the JAR file executes following.

1 ant jar

Let’s see how would Maven does the same set of tasks.

❤Maven

[pom.xml]


<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.technologyconversations</groupId>
    <artifactId>java-build-tools</artifactId>
    <packaging>jar</packaging>
    <version>1.0</version>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
        </dependency>
        <dependency>
            <groupId>org.hamcrest</groupId>
            <artifactId>hamcrest-all</artifactId>
            <version>1.3</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.2</version>
            </plugin>
            <!--verify-->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
                <version>2.12.1</version>
                <executions>
                    <execution>
                        <configuration>
                            <configLocation>config/checkstyle/checkstyle.xml</configLocation>
                            <consoleOutput>true</consoleOutput>
                            <failsOnError>true</failsOnError>
                        </configuration>
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>findbugs-maven-plugin</artifactId>
                <version>2.5.4</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-pmd-plugin</artifactId>
                <version>3.1</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

</project>

To run the Maven goal that runs both unit tests and static analysis with CheckStyle, FindBugs, and PMD, execute following.

1. mvn verify

We had to write a lot of XML that does some very basic and commonly used set of tasks.

 On real projects with a lot more dependencies and tasks, Maven pom.xml files can easily reach hundreds or even thousands of lines of XML.

Here’s how the same looks in Gradle.

❤Gradle

apply plugin: 'java'
apply plugin: 'checkstyle'
apply plugin: 'findbugs'
apply plugin: 'pmd'

version = '1.0'

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.11'
    testCompile group: 'org.hamcrest', name: 'hamcrest-all', version: '1.3'
}

task wrapper(type: Wrapper) {
    gradleVersion = '1.12'
}


Not only that the Gradle code is much shorter and, to those familiar with Gradle, easier to understand than Maven, but it actually introduces many useful tasks not covered with the Maven code we just wrote.

To get the list of all tasks that Gradle can run with the current configuration, please execute the following.

1. gradle tasks --all

Clarity, complexity and the learning curve

For newcomers, Ant is the clearest tool of all.

 Just by reading the configuration XML one can understand what it does.

However, writing Ant tasks easily gets very complex. Maven and, especially, Gradle has a lot of tasks already available out-of-the-box or through plugins. For example, by seeing the following line it is probably not clear to those not initiated into mysteries of Gradle what tasks will be unlocked for us to use.

[build.gradle]

1.apply plugin: 'java'

This simple line of code adds 20+ tasks waiting for us to use.

Ant’s readability and Maven’s simplicity are, in my opinion, false arguments that apply only during the short initial Gradle learning curve.

 Once one is used to the Gradle DSL, its syntax is shorter and easier to understand than those employed by Ant or Maven. Moreover, only Gradle offers both conventions and the creation of commands.

While Maven can be extended with Ant tasks, it is tedious and not very productive.

Gradle with Groovy brings it to the next level.

 Build Lifecycle

A Build Lifecycle is a well-defined sequence of phases, which define the order in which the goals are to be executed.

Here phase represents a stage in the life cycle. As an example, a typical Maven Build Lifecycle consists of the following sequence of phases.

There are always pre and post phases to register goals, which must run prior to, or after a particular phase.

When Maven starts building a project, it steps through a defined sequence of phases and executes goals, which are registered with each phase.

Maven has the following three standard lifecycles −

➦clean
➦default(or build)
➦site

A goal represents a specific task which contributes to the building and managing of a project.

It may be bound to zero or more build phases.

 A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation.

The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below.

The clean and package arguments are build phases while the dependency:copy-dependencies is a goal.


Here the clean phase will be executed first, followed by the dependency:copy-dependencies goal, and finally, the package phase will be executed.

Clean Lifecycle

When we execute the mvn post-clean command, Maven invokes the clean lifecycle consisting of the following phases.

🔶pre-clean
🔶clean
🔶post-clean

Maven clean goal (clean: clean) is bound to the clean phase in the clean lifecycle.

 It's clean: clean goal deletes the output of a build by deleting the build directory.

Thus, when the mvn clean command executes, Maven deletes the build directory.

We can customize this behavior by mentioning goals in any of the above phases of clean life cycle.

In the following example, We'll attach maven-antrun-plugin: run goal to the pre-clean, clean, and post-clean phases.

 This will allow us to echo text messages displaying the phases of the clean lifecycle.

We've created a pom.xml in C:\MVN\project folder.

<project xmlns = "http://maven.apache.org/POM/4.0.0"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0
   http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <groupId>com.companyname.projectgroup</groupId>
   <artifactId>project</artifactId>
   <version>1.0</version>
   <build>
      <plugins>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-antrun-plugin</artifactId>
            <version>1.1</version>
            <executions>
               <execution>
                  <id>id.pre-clean</id>
                  <phase>pre-clean</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>pre-clean phase</echo>
                     </tasks>
                  </configuration>
               </execution>

               <execution>
                  <id>id.clean</id>
                  <phase>clean</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>clean phase</echo>
                     </tasks>
                  </configuration>
               </execution>

               <execution>
                  <id>id.post-clean</id>
                  <phase>post-clean</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>post-clean phase</echo>
                     </tasks>
                  </configuration>
               </execution>
            </executions>
         </plugin>
      </plugins>
   </build>
</project>
Now open command console, go to the folder containing pom.xml and execute the following mvn command.

Maven will start processing and displaying all the phases of clean life cycle.

[INFO] Scanning for projects...
[INFO] -----------------------------------------------------------------
-
[INFO] Building Unnamed - com.companyname.projectgroup:project:jar:1.0
[INFO] task-segment: [post-clean]
[INFO] ------------------------------------------------------------------
[INFO] [antrun:run {execution: id.pre-clean}]
[INFO] Executing tasks
[echo] pre-clean phase
[INFO] Executed tasks
[INFO] [clean:clean {execution: default-clean}]
[INFO] [antrun:run {execution: id.clean}]
[INFO] Executing tasks
[echo] clean phase
[INFO] Executed tasks
[INFO] [antrun:run {execution: id.post-clean}]
[INFO] Executing tasks
[echo] post-clean phase
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------
[INFO] Total time: > 1 second
[INFO] Finished at: Sat Jul 07 13:38:59 IST 2012
[INFO] Final Memory: 4M/44M
[INFO] ------------------------------------------------------------------

You can try tuning mvn clean command, which will display pre-clean and clean.

 Nothing will be executed for the post-clean phase.

Default (or Build) Lifecycle

This is the primary life cycle of Maven and is used to build the application. It has the following 21 phases.






There are few important concepts related to Maven Lifecycles, which are worth to mention −

When a phase is called via Maven command, for example, mvn compile, only phases up to and including that phase will execute.

Different maven goals will be bound to different phases of Maven lifecycle depending upon the type of packaging (JAR / WAR / EAR).

In the following example, we will attach maven-antrun-plugin: run goal to a few of the phases of the Build Lifecycle.

This will allow us to echo text messages displaying the phases of the lifecycle.

We've updated pom.xml in C:\MVN\project folder.

<project xmlns = "http://maven.apache.org/POM/4.0.0"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0
   http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <groupId>com.companyname.projectgroup</groupId>
   <artifactId>project</artifactId>
   <version>1.0</version>
   <build>
      <plugins>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-antrun-plugin</artifactId>
            <version>1.1</version>
            <executions>
               <execution>
                  <id>id.validate</id>
                  <phase>validate</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>validate phase</echo>
                     </tasks>
                  </configuration>
               </execution>

               <execution>
                  <id>id.compile</id>
                  <phase>compile</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>compile phase</echo>
                     </tasks>
                  </configuration>
               </execution>

               <execution>
                  <id>id.test</id>
                  <phase>test</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>test phase</echo>
                     </tasks>
                  </configuration>
               </execution>

               <execution>
                  <id>id.package</id>
                  <phase>package</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>package phase</echo>
                     </tasks>
                  </configuration>
               </execution>

               <execution>
                  <id>id.deploy</id>
                  <phase>deploy</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>deploy phase</echo>
                     </tasks>
                  </configuration>
               </execution>
            </executions>
         </plugin>
      </plugins>
   </build>
</project>

Now open command console, go the folder containing pom.xml and execute the following mvn command.


[INFO] Scanning for projects...
[INFO] -----------------------------------------------------------------
-
[INFO] Building Unnamed - com.companyname.projectgroup:project:jar:1.0
[INFO] task-segment: [compile]
[INFO] -----------------------------------------------------------------
-
[INFO] [antrun:run {execution: id.validate}]
[INFO] Executing tasks
[echo] validate phase
[INFO] Executed tasks
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
C:\MVN\project\src\main\resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [antrun:run {execution: id.compile}]
[INFO] Executing tasks
[echo] compile phase
[INFO] Executed tasks
[INFO] -----------------------------------------------------------------
-
[INFO] BUILD SUCCESSFUL
[INFO] -----------------------------------------------------------------
-
[INFO] Total time: 2 seconds
[INFO] Finished at: Sat Jul 07 20:18:25 IST 2012
[INFO] Final Memory: 7M/64M
[INFO] -----------------------------------------------------------------
-

Site Lifecycle

Maven Site Plugin is generally used to create fresh documentation to create reports, deploy a site, etc. It has the following phases −

➤pre-site
➤site
➤post-site
➤site-deploy

In the following example, we will attach maven-antrun-plugin: run goal to all the phases of Site lifecycle. This will allow us to echo text messages displaying the phases of the lifecycle.

We've updated pom.xml in C:\MVN\project folder.

<project xmlns = "http://maven.apache.org/POM/4.0.0"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0
   http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <groupId>com.companyname.projectgroup</groupId>
   <artifactId>project</artifactId>
   <version>1.0</version>
   <build>
      <plugins>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-antrun-plugin</artifactId>
            <version>1.1</version>
            <executions>
               <execution>
                  <id>id.pre-site</id>
                  <phase>pre-site</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>pre-site phase</echo>
                     </tasks>
                  </configuration>
               </execution>
   
               <execution>
                  <id>id.site</id>
                  <phase>site</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>site phase</echo>
                     </tasks>
                  </configuration>
               </execution>
   
               <execution>
                  <id>id.post-site</id>
                  <phase>post-site</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>post-site phase</echo>
                     </tasks>
                  </configuration>
               </execution>
   
               <execution>
                  <id>id.site-deploy</id>
                  <phase>site-deploy</phase>
                  <goals>
                     <goal>run</goal>
                  </goals>
                  <configuration>
                     <tasks>
                        <echo>site-deploy phase</echo>
                     </tasks>
                  </configuration>
               </execution>
   
            </executions>
         </plugin>
      </plugins>
   </build>
</project>
Now open the command console, go the folder containing pom.xml and execute the following mvn command.

Maven will start processing and displaying the phases of site life cycle up to the site phase.

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------
[INFO] Building Unnamed - com.companyname.projectgroup:project:jar:1.0
[INFO] task-segment: [site]
[INFO] ------------------------------------------------------------------
[INFO] [antrun:run {execution: id.pre-site}]
[INFO] Executing tasks
[echo] pre-site phase
[INFO] Executed tasks
[INFO] [site:site {execution: default-site}]

[INFO] Generating "About" report.
[INFO] Generating "Issue Tracking" report.
[INFO] Generating "Project Team" report.
[INFO] Generating "Dependencies" report.
[INFO] Generating "Project Plugins" report.
[INFO] Generating "Continuous Integration" report.
[INFO] Generating "Source Repository" report.
[INFO] Generating "Project License" report.
[INFO] Generating "Mailing Lists" report.
[INFO] Generating "Plugin Management" report.
[INFO] Generating "Project Summary" report.

[INFO] [antrun:run {execution: id.site}]
[INFO] Executing tasks
[echo] site phase
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------
[INFO] Total time: 3 seconds
[INFO] Finished at: Sat Jul 07 15:25:10 IST 2012
[INFO] Final Memory: 24M/149M
[INFO] ------------------------------------------------------------------

 Maven

Maven is a project management and comprehension tool that provides developers a complete build lifecycle framework.

 A development team can automate the project's build infrastructure in almost no time as Maven uses a standard directory layout and a default build lifecycle.

In the case of multiple development teams environment, Maven can set-up the way to work as per standards in a very short time.

As most of the project setups are simple and reusable, Maven makes a life of developer easy while creating reports, checks, build and testing automation setups.

Maven provides developers ways to manage the following −

• Builds
• Documentation
• Reporting
• Dependencies
• SCMs
• Releases
• Distribution
• Mailing list

To summarize, Maven simplifies and standardizes the project build process.

It handles compilation, distribution, documentation, team collaboration and other tasks seamlessly.

Maven increases reusability and takes care of most of the build related tasks.

Maven Evolution

Maven was originally designed to simplify building processes in the Jakarta Turbine project.

There were several projects and each project contained slightly different ANT build files. JARs were checked into CVS.

Apache group then developed Maven which can build multiple projects together, publish projects information, deploy projects, share JARs across several projects and help in collaboration of teams.

Objective

The primary goal of Maven is to provide the developer with the following −

A comprehensive model for projects, which is reusable, maintainable, and easier to comprehend.

Plugins or tools that interact with this declarative model.

Maven project structure and contents are declared in an XML file, pom.xml, referred to as Project Object Model (POM), which is the fundamental unit of the entire Maven system. In later chapters, we will explain POM in detail.

Convention over Configuration

Maven uses Convention over Configuration, which means developers are not required to create build process themselves.

Developers do not have to mention each and every configuration detail.

 Maven provides sensible default behavior for projects.

When a Maven project is created, Maven creates a default project structure.

  The developer is only required to place files accordingly and he/she need not define any configuration in pom.xml.

As an example, the following table shows the default values for project source code files, resource files, and other configurations.

 Assuming, ${basedir} denotes the project location −


In order to build the project, Maven provides developers with options to mention life-cycle goals and project dependencies (that rely on Maven plugin capabilities and on its default conventions).

Much of the project management and build related tasks are maintained by Maven plugins.

Developers can build any given Maven project without the need to understand how the individual plugins work.

We will discuss Maven Plugins in detail in the later chapters.

Features of Maven

• Simple project setup that follows best practices.

• Consistent usage across all projects.

• Dependency management including automatic updating.

• A large and growing repository of libraries.

• Extensible, with the ability to easily write plugins in Java or scripting languages.

• Instant access to new features with little or no extra configuration.

Model-based builds − Maven is able to build any number of projects into predefined output types such as jar, war, metadata.

A coherent site of project information − Using the same metadata as per the build process, Maven is able to generate a website and a PDF including complete documentation.

Release management and distribution publication − Without additional configuration, maven will integrate with your source control system such as CVS and manages the release of a project.

Backward Compatibility − You can easily port the multiple modules of a project into Maven 3 from older versions of Maven. It can support the older versions also.

Automatic parent versioning − No need to specify the parent in the sub-module for maintenance.

Parallel builds − It analyzes the project dependency graph and enables you to build schedule modules in parallel.
Using this, you can achieve the performance improvements of 20-50%.

Better Error and Integrity Reporting − Maven improved error reporting, and it provides you with a link to the Maven wiki page where you will get a full description of the error.

 Maven Build Lifecycle 

The Maven build follows a specific life cycle to deploy and distribute the target project.

There are three built-in life cycles:

• default: the main life cycle as it’s responsible for project deployment
• clean: to clean the project and remove all files generated by the previous build
• site: to create the project’s site documentation

Each life cycle consists of a sequence of phases.

The default build life cycle consists of 23 phases as it’s the main build lifecycle.

On the other hand, clean life cycle consists of 3 phases, while the site lifecycle is made up of 4 phases.

 Maven Phase

A Maven phase represents a stage in the Maven build lifecycle.

 Each phase is responsible for a specific task.

Here are some of the most important phases in the default build lifecycle:

• validate: check if all information necessary for the build is available
• compile: compile the source code
• test-compile: compile the test source code
• test: run unit tests
• package: package compiled source code into the distributable format (jar, war, …)
• integration-test: process and deploy the package if needed to run integration tests
• install: install the package to a local repository
• deploy: copy the package to the remote repository

For the full list of each lifecycle’s phases, check out the Maven Reference.

Phases are executed in a specific order.

This means that if we run a specific phase using the command:


This won’t only execute the specified phase but all the preceding phases as well.

For example, if we run the deploy phase – which is the last phase in the default build lifecycle – that will execute all phases before the deploy phase as well, which is the entire default lifecycle:

Maven Goal 

Each phase is a sequence of goals, and each goal is responsible for a specific task.

When we run a phase – all goals bound to this phase are executed in order.

Here are some of the phases and default goals bound to them:

• compiler: compile – the compile goal from the compiler plugin is bound to the compile phase
• compiler:testCompile is bound to the test-compile phase
• surefire: a test is bound to test phase
• install: install is bound to install phase
• jar: jar and war: war is bound to package phase

We can list all goals bound to a specific phase and their plugins using the command:


For example, to list all goals bound to the compile phase, we can run:

1.mvn help:describe -Dcmd=compile

And get the sample output:

Which, as mentioned above, means the compile goal from compiler plugin is bound to the compile phase.

Maven - Build Profiles

 Build Profile

A Build profile is a set of configuration values, which can be used to set or override default values of Maven build.

Using a build profile, you can customize build for different environments such as Production v/s Development environments.

Profiles are specified in a pom.xml file using its activeProfiles/profiles elements and are triggered in a variety of ways.

 Profiles modify the POM at build time and are used to give parameters different target environments (for example, the path of the database server in the development, testing, and production environments).

Types of Build Profile

Build profiles are major of three types.

Profile Activation

A Maven Build Profile can be activated in various ways.

• Explicitly using command console input.
• Through maven settings.
• Based on environment variables (User/System variables).
• OS Settings (for example, Windows family).
• Present/missing files.

Profile Activation Examples

Let us assume the following directory structure of your project −



Now, under src/main/resources, there are three environment specific files −

Explicit Profile Activation

In the following example, we will attach maven-antrun-plugin: run goal to test the phase.

This will allow us to echo text messages for different profiles.

We will be using pom.xml to define different profiles and will activate profile at command console using maven command.

Assume, we've created the following pom.xml in C:\MVN\project folder.

<project xmlns = "http://maven.apache.org/POM/4.0.0"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0
   http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <groupId>com.companyname.projectgroup</groupId>
   <artifactId>project</artifactId>
   <version>1.0</version>
   <profiles>
      <profile>
         <id>test</id>
         <build>
            <plugins>
               <plugin>
                  <groupId>org.apache.maven.plugins</groupId>
                  <artifactId>maven-antrun-plugin</artifactId>
                  <version>1.1</version>
                  <executions>
                     <execution>
                        <phase>test</phase>
                        <goals>
                           <goal>run</goal>
                        </goals>
                        <configuration>
                           <tasks>
                              <echo>Using env.test.properties</echo>
                              <copy file="src/main/resources/env.test.properties"
                                 tofile="${project.build.outputDirectory}
                                 /env.properties"/>
                           </tasks>
                        </configuration>
                     </execution>
                  </executions>
               </plugin>
            </plugins>
         </build>
      </profile>
   </profiles>
</project>
Now open the command console, go to the folder containing pom.xml and execute the following mvn command. Pass the profile name as argument using -P option.

Maven will start processing and displaying the result of the test build profile.

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------
[INFO] Building Unnamed - com.companyname.projectgroup:project:jar:1.0
[INFO] task-segment: [test]
[INFO] ------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]

[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!

[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]

[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!

[INFO] skip non existing resourceDirectory C:\MVN\project\src\test\resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory: C:\MVN\project\target\surefire-reports

-------------------------------------------------------
T E S T S
-------------------------------------------------------

There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[echo] Using env.test.properties
[INFO] Executed tasks

[INFO] ------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------

[INFO] Total time: 1 second
[INFO] Finished at: Sun Jul 08 14:55:41 IST 2012
[INFO] Final Memory: 8M/64M
[INFO] ------------------------------------------------------------------

Now as an exercise, you can perform the following steps −

⭐Add another profile element to profiles element of pom.xml (copy existing profile element and paste it where profile elements end).

⭐Update id of this profile element from test to normal.

⭐Update task section to echo env.properties and copy env.properties to a target directory.

⭐Again repeat the above three steps, update id to prod and task section for env.prod.properties.

That's all.

Now you've three build profiles ready (normal/test/prod).

Now open the command console, go to the folder containing pom.xml and execute the following mvn commands. Pass the profile names as an argument using -P option.

Check the output of the build to see the difference.

Profile Activation via Maven Settings

Open Maven settings.xml file available in %USER_HOME%/.m2 directory where %USER_HOME% represents the user home directory. If the settings.xml file is not there, then create a new one.

Add test profile as an active profile using active Profiles node as shown below in the example.

<settings xmlns = "http://maven.apache.org/POM/4.0.0"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
   http://maven.apache.org/xsd/settings-1.0.0.xsd">
   <mirrors>
      <mirror>
         <id>maven.dev.snaponglobal.com</id>
         <name>Internal Artifactory Maven repository</name>
         <url>http://repo1.maven.org/maven2/</url>
         <mirrorOf>*</mirrorOf>
      </mirror>
   </mirrors>
   <activeProfiles>
      <activeProfile>test</activeProfile>
   </activeProfiles>
</settings>
Now open command console, go to the folder containing pom.xml and execute the following mvn command. Do not pass the profile name using -P option. Maven will display result of test profile being an active profile.

Profile Activation via Environment Variables

Now remove an active profile from maven settings.xml and update the test profile mentioned in pom.xml. Add activation element to profile element as shown below.

The test profile will trigger when the system property "env" is specified with the value "test".

 Create an environment variable "env" and set its value as "test".

<profile>
   <id>test</id>
   <activation>
      <property>
         <name>env</name>
         <value>test</value>
      </property>
   </activation>
</profile>

Let's open command console, go to the folder containing pom.xml and execute the following mvn command.

Profile Activation via Operating System

Activation element to include os detail as shown below.

This test profile will trigger when the system is Windows XP.

<profile>
   <id>test</id>
   <activation>
      <os>
         <name>Windows XP</name>
         <family>Windows</family>
         <arch>x86</arch>
         <version>5.1.2600</version>
      </os>
   </activation>
</profile>

Now open command console, go to the folder containing pom.xml and execute the following mvn commands.

Do not pass the profile name using -P option. Maven will display the result of the test profile is an active profile.

Profile Activation via Present/Missing File

Now activation element to include OS details as shown below.

 The test profile will trigger when target/generated-sources/axis tools/wsdl2java/com/company name/group is missing.

<profile>
   <id>test</id>
   <activation>
      <file>
         <missing>target/generated-sources/axistools/wsdl2java/
           com/companyname/group</missing>
      </file>
   </activation>
</profile>

Now open the command console, go to the folder containing pom.xml and execute the following mvn commands.

 Do not pass the profile name using -P option. Maven will display the result of the test profile is an active profile.

Maven - Manage Dependencies

One of the core features of Maven is Dependency Management. Managing dependencies is a difficult task once we've to deal with multi-module projects (consisting of hundreds of modules/sub-projects). Maven provides a high degree of control to manage such scenarios.

Transitive Dependencies Discovery

It is pretty often a case, when a library, say A, depends upon other libraries, say B. In case another project C wants to use A, then that project requires to use library B too.

Maven helps to avoid such requirements to discover all the libraries required. Maven does so by reading project files (pom.xml) of dependencies, figure out their dependencies and so on.

We only need to define direct dependency in each project pom. Maven handles the rest automatically.

With transitive dependencies, the graph of included libraries can quickly grow to a large extent. Cases can arise when there are duplicate libraries. Maven provides a few features to control the extent of transitive dependencies.

Dependency Scope

Transitive Dependencies Discovery can be restricted using various Dependency Scope as mentioned below.

Top 10 Testing Automation Tools for Software Testing

1. Selenium

Selenium is a testing framework to perform web application testing across various browsers and platforms like Windows, Mac, and Linux.

Selenium helps the testers to write tests in various programming languages like Java, PHP, C#, Python, Groovy, Ruby, and Perl.


It offers record and playback features to write tests without learning Selenium IDE.


Selenium proudly supports some of the largest, yet well-known browser vendors who make sure they have Selenium as a native part of their browser.




Selenium is undoubtedly the base for most of the other software testing tools in general.

Learn more about Selenium.

2. TestingWhiz

TestingWhiz is a test automation tool with the code-less scripting by Cygnet Infotech, a CMMi Level 3 IT solutions provider.


TestingWhiz tool’s Enterprise edition offers a complete package of various automated testing solutions like web testing, software testing, database testing, API testing, mobile app testing, regression test suite maintenance, optimization, and automation, and cross-browser testing.

TestingWhiz offers various important features like:

⚽Keyword-driven, data-driven testing, and distributed testing
⚽Record and playback test automation framework
⚽Object Eye Internal Recorder
⚽290+ inbuilt testing commands in addition to in-built JavaScript
⚽Integration with bug tracking tools like Jira, Mantis, and FogBugz
⚽Integration with test management tools like HP Quality Center
⚽Risk-based testing
⚽Continuous Integration and Delivery in Agile cycles

Learn more about TestingWhiz.

3. HPE Unified Functional Testing (HP – UFT formerly QTP)

HP QuickTest Professional was renamed to HPE Unified Functional Testing.

HPE UFT offers testing automation for functional and regression testing for software applications.

Visual Basic Scripting Edition scripting language is used by this tool to register the test processes and operates the various objects and controls in testing the applications.


QTP offers various features like:

🎈Integration with Mercury Business Process Testing and Mercury Quality Center
🎈Unique Smart Object Recognition
🎈Error handling mechanism
🎈Creation of parameters for objects, checkpoints, and data-driven tables
🎈Automated documentation

Learn more about HP – UFT.

4. TestComplete

TestComplete is a functional testing platform that offers various solutions to automate testing for desktop, web, and mobile applications by SmartBear Software.

TestComplete offers the following features:

🦋GUI testing
🦋Scripting Language Support – JavaScript, Python, VBScript, JScript, DelphiScript, C++Script & 🦋C#Script
🦋Test visualizer
🦋Scripted testing
🦋Test recording and playback

Learn more about TestComplete.

5. Ranorex

Ranorex Studio offers various testing automation tools that cover testing all desktop, web, and mobile applications.







Learn more about Ranorex.

6. Sahi

Sahi is a testing automation tool to automate web applications testing.

 The open source Sahi is written in Java and JavaScript programming languages.

Sahi provides the following features:


✪Performs multi-browser testing
✪Supports ExtJS, ZK, Dojo, YUI, etc. frameworks
✪Record and playback on browser testing

Learn more about Sahi.

7. Watir

Watir is an open source testing tool made up of Ruby libraries to automate web application testing. It is pronounced as “water.”



Watir offers the following features:

• Tests any language-based web application
• Cross-browser testing
• Compatible with business-driven development tools like RSpec, Cucumber, and Test/Unit
• Tests web page’s buttons, forms, links, and their responses

Learn more about Watir.

8. Tosca Testsuite

Tosca Testsuite by Tricentis uses model-based test automation to automate software testing.





Tosca Testsuite comes with the following capabilities:

🔼Plan and design test case