Test NG-Testing Tools

Java-Examples

                                                                                                                                                                                                                    Show all | Close all
  • Overview

    • What is testing

      Testing can never completely identify all the defects within software.[2] Instead, it furnishes a criticism or comparison that compares the state and behavior of the product against oracles-principles or mechanisms by which someone might recognize a problem. These oracles may include (but are not limited to) specifications, contracts,[3] comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria. A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions.[4] The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for testing team members. Information derived from software testing may be used to correct the process by which software is developed.[5] Every software product has a target audience. For example, the audience for video game software is completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it can assess whether the software product will be acceptable to its end users, its target audience, its purchasers, and other stakeholders.

      The Reason & Importance of Testing


      It is very important to have decent quality software's. Having this means the quality should match many requirements such as keeping the easy use of GUI's, as well as containing faults and failures and many more. A lot of effort is required to keep this quality to a reasonable standard. Testing is one of the most important parts in quality assurance especially in the development stages. As the development of the program comes to an end it becomes harder to fix errors, in fact becomes harder to spot errors. This would mean, perhaps, to check each section during the development so that the errors can be spotted and fixed before progressing to the next stages.
      Testing should be done during the development stages and if it is not done during the development stages then it is more than likely that there will be a lot of bugs and errors. Some problems which may not have been seen during the development stages, without testing at the end, could be something like a function being used whilst the stack is empty. This could lead to a system crashing. However, if testing is done this could be spotted before proceeding to the next stage.
      Humans are prone to make mistakes and so if they do everything then it may not be as efficient. Some code may be missed out with humans and so this could cause errors in the system.
    • why we use testing tools


      Testing tools can help automate tasks such as product installation, test data creation, GUI interaction, problem detection (consider parsing or polling agents equipped with oracles), defect logging, etc., without necessarily automating tests in an end-to-end fashion. One must keep satisfying popular requirements when thinking of test automation:
      Platform and OS independence
      Data driven capability (Input Data, Output Data, Metadata)
      Customizable Reporting (DB Access, crystal reports)
      Easy debugging and logging
      Version control friendly - minimal binary files
      Extensible & Customizable (Open APIs to be able to integrate with other tools)
      Common Driver (For example, in the Java development ecosystem, that means Ant or Maven and the popular IDEs). This enables tests to integrate with the developers' workflows.
      Support unattended test runs for integration with build processes and batch runs. Continuous integration servers require this.
      Email Notifications (automated notification on failure or threshold levels). This may be the test runner or tooling[clarification needed] that executes it.
      Support distributed execution environment (distributed test bed)
      Distributed application support (distributed SUT)
      As the software industry grows, it becomes more and more competitive and advanced for businesses to produce such good quality software. With this also comes the reliability and deadlines which must be met. Testing plays a big part in the case of deadlines as testing can take a long time on the software. The production of the software and the quality together must be increased for businesses to produce the best possible software. Testing, therefore, has to be done throughout the process of programming the software. Manual testing takes too long and can waste a lot of time. With the aid of testing tools this can increase efficiency and get the deadlines met.
    • Types of testing tools

      What are testing tools ?


      Testing tools are a form of automated testing. It is basically using programs to do different testing tasks i.e. doing the tests through some form of automated method. They are computerized and help in assisting every type of testing. Some of these testing tasks include checking the conditions, also checking the predicted results with the actual results along with many other types of testing involved. A lot of these testing tools have commonly used coding languages such as Java and C. The testing tools themselves have been made using these programming languages. A lot of the tools used have different options available to help with testing. This can be very useful when producing the essential reports of that particular product.

      Different Methodologies Used For Testing


      There are different methodologies that are can be used when implementing testing tools. The testing methodologies can be used together or individually. It all depends on what you are testing as they provide better resources for different tasks. Below are a few of the main different types that are used but there are other types of testing that can be used:

      Unit Testing

      This is the software used for verification and validation. It's a method in which the programmer can test all the separate code and see if it is viable to use. This type of testing is based on a small scale and uses small units of the program. When looking at procedural programming the unit can be any individual function or a procedure which is written in the same language as the production code.

      White Box Testing

      This is also known as clear box testing, glass box testing, translucent box testing or structural testing. It uses the internal perspective of the system and then designs test cases based on this internal structure. Basically the code itself and all the conditions, statements and paths along with it are tested. Programming skills are required for noticing all the paths through the software. White box testing does many things such as analyzing the data flow, control flow, information flow and coding practices.

      Regression Testing

      This is a type of software testing which basically looks for software regressions. The regressions can happen whenever the software stops working as it is meant to. The testing makes sure that any bugs or changes have been fixed which may have caused previous working functions to have failed as a result of the newly added features. It is better to do this type of testing under the automated tool environment. The regression testing may take place once the programmer has tried to fix a problem or has purposely added in code to give out errors.

      Integration Testing

      This is where the separate software modules are put together and are then tested as a whole. This normally takes place after unit testing has been done. The point of doing integration testing is because it verifies the functional and performance requirements of the design items. It is component of Extreme Programming (XP). Two different ways of doing integration testing is bottom-up and top-down.
  • TestNG

    TestNG is a testing framework inspired from JUnit and NUnit but introducing some new functionalities that make it more powerful and easier to use, such as:
    • Annotations.
    • Run your tests in arbitrarily big thread pools with various policies available (all methods in their own thread, one thread per test class, etc...).
    • Test that your code is multithread safe.
    • Flexible test configuration.
    • Support for data-driven testing (with @DataProvider).
    • Support for parameters.
    • Powerful execution model (no more TestSuite).
    • Supported by a variety of tools and plug-ins (Eclipse, IDEA, Maven, etc...).
    • Embeds BeanShell for further flexibility.
    • Default JDK functions for runtime and logging (no dependencies).
    • Dependent methods for application server testing.
    TestNG is designed to cover all categories of tests:  unit, functional, end-to-end, integration, etc...
    I started TestNG out of frustration for some JUnit deficiencies which I have documented on my weblog here and here Reading these entries might give you a better idea of the goal I am trying to achieve with TestNG.  You can also check out a quick overview of the main features and an article describing a very concrete example where the combined use of several TestNG's features provides for a very intuitive and maintainable testing design.
  • Maven-Plugin

    TestNG Maven plug-ins

    Table of Contents

    <!-- begin maven2

    Maven 2

    Maven 2 supports TestNG out of the box without the need to download any additional plugins (other than TestNG itself). It is recommended that you use version 2.4 or above of the Surefire plugin (this is the case in all recent versions of Maven).
    You can find the full instructions on the Maven Surefire Plugin web site. There are also TestNG-specific instructions.

    Specifying your pom.xml

    The dependency in your project should look like the following:
     <dependency>
       <groupId>org.testng</groupId>
       <artifactId>testng</artifactId>
       <version>6.1.1</version>
       <scope>test</scope>
     </dependency>
    

    Sample Report

    A sample surefire report with TestNG can be found here.


    Maven TestNG Archetype (Martin Gilday)

    Martin Gilday has added a new archetype for Maven2: to create a project using the archetype you simply have to specify my repository and the archetype ID.
      mvn archetype:create -DgroupId=org.martingilday -DartifactId=test1 -DarchetypeGroupId=org.martingilday -DarchetypeArtifactId=testng-archetype
        -DarchetypeVersion=1.0-SNAPSHOT -DremoteRepositories=http://www.martingilday.org/repository/
    Of course substitute in your own groupId and artifactId.
    Don't forget to keep checking back at Martin's blog for more updates.


    Maven 1 (by Andrew Glover)

    The TestNG Maven plug-in is quite simple and consists of two goals and a series of optional properties.
    Currently the 1.1 version of the plug-in is bundled with official releases of TestNG. To utilize the plug-in, copy the maven-testng-plugin-.jar to the $MAVEN_HOME/plugins directory.
    For the latest version of the plug-in (1.2 as of 12/12/05), update your maven.repo.remote to include http://www.vanwardtechnologies.com/repository/ and then issue the following command: maven plugin:download. Maven will issue a series of questions, answer them as follows:

    artifactId: maven-testng-plugin
    groupId: testng
    version: 1.2

    Goals

    Goal Description
    testng Runs TestNG
    testng:junit-report Creates a JUnit style report

    Properties

    Property Optional? Description
    maven.testng.suitexml.name Yes XML file name- defaults to testng.xml
    maven.testng.suitexml.dir Yes Directory where XML file lives. Defaults to ${basedir}/test/conf
    maven.testng.output.dir Yes Default report directory. Defaults to ${maven.build.dir}/testng-output
    maven.testng.report.dir Yes Directory for JUnit reports. Defaults to ${maven.build.dir}/testngJunitReport
-->
  • IDEA-plugin

    TestNG IDEA Plug-in

    IDEA 7

    TestNG is supported natively in IDEA 7. The full documentation can be found here.

    IDEA 6 and older

    TestNG has an IDEA plug-in that mirrors much of the behavior of the built-in JUnit support. You should be able to run tests within IDEA without defining any files externally, as well as quickly and easily migrate JUnit code. The plug-in also provides the same output test view as JUnit tests. Installation New versions of the plugin are constantly uploaded to the IDEA plug-in repository.
    • From IDEA, go to Preferences -> Plugins.
    • Click over to the Available Plugins tab.
    The latest version of the TestNG plugin will be listed there, ready to download and install.  Also, you can go to the TestNG IDEA plug-in project page and download its source from there.
    Please note that this plug-in only works on IDEA 5.0 and 6.0.
    Creating a TestNG Run/Debug configuration
    Once you have installed the plug-in and restarted IDEA, and have some TestNG classes you would like to run, simply open the Run/Debug window. You will see a TestNG tab, where you can add a configuration.
    There are a number of methods for determining the set of tests that will be run. These are:
    • Package: Specify a package to run. All tests in this package and below will be included.
    • Group: Specify a TestNG group to run.
    • Suite: Specify an external testng.xml file to run.
    • Class: Run all tests in a single class.
    • Method: Run a single test method.
    Once you create the run configuration, you can run it. Upon running, the plug-in will launch an external process to run your tests. The test results will be display in a tree view, with passed and failed tests highlighted. You can narrow down on the console output for a specify test by clicking on it, while double clicking a test will navigate to its source code.
  • How to install TestNG in eclipse

    TestNG Eclipse plug-in

    The TestNG Eclipse plug-in allows you to run your TestNG tests from Eclipse and easily monitor their execution and their output. It has its own project repository called testng-eclipse.

    Table of Contents

      1 - Installation
      2 - Creating a TestNG class
      3 - Launch configurations
      3.1 - From a class file
      3.2 - From groups
      3.3 - From an XML file
      3.4 - From a method
      3.5 - Specifying listeners and other settings
      4 - Viewing the results
      5 - Search
      6 - The Summary tab
      7 - Converting JUnit tests
      8 - Quick fixes
       <!-- Installation

    1 - Installation

    Once you have installed the plug-in, restart Eclipse and select the menu Window / Show View / Other...  and you should see the TestNG view listed in the Java category.

    2 -Creating a TestNG class

    To create a new TestNG class, select the menu File / New / TestNG:
    If you currently have a Java file open in the editor or if you have a Java file selected in the Navigator, the first page of the wizard will show you a list of all the public methods of that class and it will give you the option to select the ones you want to test. Each method you select on this page will be included in the new TestNG class with a default implementation that throws an exception, so you remember to implement it.
    The next page lets you specify where that file will be created, whether it should contain default implementation for some configuration methods, if you'd like a data provider and finally, if a testng.xml file should be generated.
    The plug-in will make a guess about the best location where this file should be created (for example, if you are using Maven, the default location will be under src/test/java).

    3 - Launch configuration

    Once you have created classes that contain TestNG annotations and/or one or more testng.xml files, you can create a TestNG Launch Configuration.  Select the Run / Run... (or Run / Debug...) menu and create a new TestNG configuration:
    You should change the name of this configuration and pick a project, which can be selected by clicking on the Browse... button at the top of the window.
    Then you choose to launch your TestNG tests in the following ways:

    4.2.1 - From a class file

    Make sure the box near Class is checked and then pick a class from your project.  You can click on the Browse... button and pick it directly from a list.  This list only contains classes that contain TestNG annotations:

    3.2 - From groups

    If you only want to launch one or several groups, you can type them in the text field or pick them from a list by clicking on the Browse... button 

    3.3 - From a definition file

    Finally, you can select a suite definition from your project. It doesn't have to be named testng.xml, the plug-in will automatically identify all the applicable TestNG XML files in your project:

    3.4 - From a method

    This launch isn't accomplished from the Launch dialog but directly from your Outline view:
    You can right-click on any test methods and select Run as... / TestNG test and only the selected method will be run (not shown on the above screenshot because I couldn't find a way to capture a contextual menu).Method launching is also available from the Package Explorer view and from the Java Browser perspective.
    Once you have selected one of these launches, you can also choose the logging of level. Then you can launch the tests by pressing the Debug (or Run) button, which will switch you to the Debug perspective and will open the main TestNG view.

    3.5 -Specifying listeners and other settings

    As you saw above, the plug-in will let you start tests in many different ways: from an XML file, from a method, a class, etc... When you are running an XML file, you can specify all the settings you want for this run in the XML file, but what if you want to run a package in parallel mode with specific listeners? How can you configure the settings for all the launches that are not done from an XML file? In order to give you access to the most flexibility, TestNG lets you specify an XML suite file for all these launches, which you can find in the Preferences menu:
    If you specify a valid suite file as "XML template file", TestNG will reuse all the settings found in this XML file, such as parallel, name, listeners, thread pool size, etc... Only the <test> tags in this file will be ignored since the plug-in will replace these by a generated <test> tag that represents the launch you chose.

    4 - Viewing the test results

    The above view shows a successful run of the tests:  the bar is green and no failed tests are reported.  The All tests tab shows you a list of all the classes and methods that were run.
    If your test run contains failures, the view will look like this:
    You can use the Failed tests tab to display only these tests that failed, and when you select such a test, the stack trace will be shown on the right-hand pane.  You can double click on the offending line to be taken directly to the failure in your code.

    5 - Search

    When you have hundreds of tests running, finding a specific one is not always easy, so you can type a few letters of the test method or its parameters in the Search box and the content of the tree will automatically narrow down to methods matching your search. Note in the screen shot above that the search also works on parameters provided by @DataProvider.

    6 - Summary

    The Summary tab gives you statistics on your test run, such as the timings, the test names, the number of methods and classes, etc… Since the results are shown in a table, you can also sort on any criterion you like for easier parsing. This is especially handy when you are trying to determine what tests take the longest time.
    The search box works in this view as well, and note that in the screen shot below, the Time column is sorted in decreasing order:

    7 - Converting JUnit tests

    You can easily convert JUnit 3 and JUnit 4 tests to TestNG. Your first option is to use the Quick Fix function:


    Convert from JUnit 3

    Convert from JUnit 4
    You can also convert packages or entire source folders with the conversion refactoring:
    The refactoring wizard contains several pages:
    This page lets you generate a testng.xml automatically. You can configure whether to include your test classes individually or by package, the suite and test name and also whether these tests should run in parallel.
    This page gives you an overview of the changes that are about to be performed. You can also decide to exclude certain files from the refactoring. When you are done, press the "Finish" button. Like all Eclipse refactorings, you can undo all these changes in one click:

    8 - Quick fixes

    The TestNG Eclipse plug-in offers several quick fixes while you are editing a TestNG class (accessible with Ctrl-1 on Windows/Linux and ⌘-1 on Mac OS):

    Convert to JUnit

    This was covered in the previous section.

    Pushing and pulling @Test annotations

    If you have several test methods annotated with @Test and you'd like to replace them all with a single @Test annotation at the class level, choose the "Pull annotation" quick fix:
    Reciprocally, you can move a class level @Test annotation onto all your public methods:

    Automatically importing asserts

    Apply a quick fix on an assert method to automatically import it:






  • -->
  • Download

    Downloading TestNG

    Current Release Version

    The latest version of TestNG can be downloaded from Maven Central or here for ant users.
    For the Eclipse plug-in, we suggest using the update site:
    • Select Help / Software updates / Find and Install.
    • Search for new features to install.
    • New remote site.
    • For Eclipse 3.4 and above, enter http://beust.com/eclipse.
    • For Eclipse 3.3 and below, enter http://beust.com/eclipse1.
    • Make sure the check box next to URL is checked and click Next.
    • Eclipse will then guide you through the process.
    You can also install older versions of the plug-ins here. Note that the URL's on this page are update sites as well, not direct download links. TestNG is also hosted on GitHub, where you can download the source and build the distribution yourself:
    $ git clone git://github.com/cbeust/testng.git
    $ cd testng
    $ cp ivy-2.1.0.jar ~/.ant/lib
    $ ant
    
    You will then find the jar file in the target directory

    Beta Version

    The beta version contains changes that have been committed to the repo since the current release.
    Take a look at CHANGES.txt to see if the change you want is included in the beta (listed under "Current").
    You can download the beta version here.