DOCSLIB.ORG

Test-Driven Development:Concepts, Taxonomy,And Future Direction

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Test-Driven Development:Concepts, Taxonomy,And Future Direction COVER FEATURE Test-Driven Development: Concepts, Taxonomy, and Future Direction Test-driven development creates software in very short iterations with minimal upfront design. Poised for widespread adoption, TDD has become the focus of an increasing number of researchers and developers. David Janzen he test-driven development strategy method, a close examination of the term reveals a Simex LLC requires writing automated tests prior to more complex picture. developing functional code in small, rapid Hossein iterations. Although developers have been The test aspect Saiedian T applying TDD in various forms for several In addition to testing, TDD involves writing auto­ University decades,1 this software development strategy has mated tests of a program’s individual units. A unit of Kansas continued to gain increased attention as one of the is the smallest possible testable software component. core extreme programming practices. There is some debate about what exactly constitutes XP is an agile method that develops object-ori­ a unit in software. Even within the realm of object- ented software in very short iterations with little oriented programming, both the class and method upfront design. Although not originally given this have been suggested as the appropriate unit. name, TDD was described as an integral XP prac­ Generally, however, the method or procedure is the tice necessary for analysis, design, and testing that smallest possible testable software component. also enables design through refactoring, collective Developers frequently implement test drivers and ownership, continuous integration, and programmer function stubs to support the execution of unit tests. courage. Test execution can be either a manual or automated Along with pair programming and refactoring, process and can be performed by developers or des­ TDD has received considerable individual attention ignated testers. Automated testing involves writing since XP’s introduction. Developers have created unit tests as code and placing this code in a test har­ tools specifically to support TDD across a range of ness or framework such as JUnit. Automated unit languages, and they have written numerous books testing frameworks minimize the effort of testing, explaining how to apply TDD concepts. Re­ reducing a large number of tests to a click of a but­ searchers have begun to examine TDD’s effects on ton. In contrast, during manual test execution devel­ defect reduction and quality improvements in aca­ opers and testers must expend effort proportional demic and professional practitioner environments, to the number of tests executed. and educators have started to examine how to inte­ Traditionally, unit testing occurred after devel­ grate TDD into computer science and software opers coded the unit. This can take anywhere from engineering pedagogy. Some of these efforts have a few minutes to a few months. The unit tests might been implemented in the context of XP projects, be written by the same programmer or by a desig­ while others are independent of them. nated tester. With TDD, the programmer writes the unit tests prior to the code under test. As a result, TEST-DRIVEN DEVELOPMENT DEFINED the programmer can immediately execute the tests Although its name implies that TDD is a testing after they are written. 0018-9162/05/$20.00 © 2005 IEEE P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y September 2005 43 The driven aspect and what that program’s interface should look like Some definitions of TDD imply that it is is a radical concept for most software developers. TDD assumes primarily a testing strategy. For example, in that the software JUnit in Action (Manning Publications, The development aspect design is either 2003), Vincent Massol and Ted Husted stated Intended to aid in constructing software, TDD incomplete that is not in itself a software development methodol­ ogy or process model. It is a practice, a way of or pliable Test-driven development (TDD) is a program­ developing software to be used with other prac­ and open ming practice that instructs developers to write tices, in a particular order and frequency and in the to changes. new code only if an automated test has failed, context of a process model. TDD has emerged and to eliminate duplication. The goal of TDD within a particular set of process models. It can be is ‘clean code that works.’ applied as a microprocess within the context of many different process models. However, according to XP and TDD pioneer TDD produces a set of automated unit tests that Ward Cunningham, “Test-first coding is not a test­ provide some side effects in the development ing technique.” TDD is known by various names process. The practice assumes the automated tests including test-first programming, test-driven will not be thrown away once a design decision is design, and test-first design. The driven in test-dri­ made. Instead, the tests become a vital component ven development focuses on how TDD leads analy­ of the development process, providing quick feed­ sis, design, and programming decisions. TDD back to any changes to the system. If a change assumes that the software design is either incom­ causes a test to fail, the developer knows immedi­ plete or pliable and open to changes. In the context ately after making the change, while the test is still of XP, TDD subsumes many analysis decisions. The fresh in the developer’s mind. Among the draw­ customer should be “on-site” in XP. Test writing is backs, that developer must now maintain both the one of the first steps in deciding what the program production code and the automated tests. should do, which is essentially an analysis step. The Agile Alliance offers another definition that cap­ TDD’S HISTORICAL AND MODERN CONTEXTS tures this idea (www.agilealliance.org/programs/ Despite the lack of attention in undergraduate roadmaps/Roadmap/tdd/tdd_index.htm): curriculum and inconclusive reports of usage in industry, a wide range of software tools exist to sup­ Test-driven development (TDD) is the craft of pro­ port testing, making TDD’s emergence possible. ducing automated tests for production code, and using that process to drive design and program­ Software development methodologies ming. For every tiny bit of functionality in the pro­ A software development process or methodol­ duction code, you first develop a test that specifies ogy defines the order, control, and evaluation of the and validates what the code will do. You then pro­ basic tasks involved in creating software. Software duce exactly as much code as will enable that test process methodologies range in complexity and to pass. Then you refactor (simplify and clarify) control from largely informal to highly structured. both the production code and the test code. Developers classify these methodologies as pre­ scriptive or agile and label the specific types as To promote testing to an analysis and design step waterfall, spiral, incremental, or evolutionary. the practice of refactoring must be introduced. When an organization states that it uses a par­ Refactoring changes the structure of an existing ticular methodology, it often applies a combination body of code without changing its external behav­ of smaller, finer-grained methodologies on a pro­ ior. A test may pass, but the code may be inflexible ject scale instead. For example, an organization or overly complex. By refactoring the code, the test might apply an incremental development model, should still pass but the code will be improved. building small, cumulative slices of a project’s fea­ Understanding that TDD is more about analysis tures. In each increment, the developers could apply and design than it is about testing is one of the most a waterfall or linear method of determining require­ challenging conceptual shifts for new adopters of ments, designing a solution, coding, testing, and the practice. Program testing has traditionally then integrating. Depending on the size of the incre­ assumed the existence of a program. The TDD idea ments and the waterfall’s time frame, the process that a test can be written before the program or that could be labeled differently, with potentially very test can aid in deciding what program code to write different results in terms of quality and developer 44 Computer satisfaction. If we break a software project into N can vary widely. Some testing can be con­ increments where Ii represents each increment, then ducted early—concurrent with other coding The order the equation ΣN I can represent the entire project. activities. Test-driven development reorders i = 1 i in which If N is reasonably large, we can label this as an these steps to an advantage. By placing fine- incremental project. However, if N ≤ 2, we would grained unit tests before just enough code to construction label this as a waterfall project. satisfy that test, TDD can affect many aspects tasks occur If the increments require modifying a significant of a software development methodology. influences a amount of overlapping software, we can say that project’s label our methodology is more iterative in nature. TDD’s historical context and its quality. Specifically, for project P consisting of code C and Test-driven development has emerged in ΣN iterations I= i = 1Ii, if Ci is the code affected by iter­ conjunction with the rise of agile process ∩ ation Ii, and if project P is iterative, then Ci Ci + 1 models. Both have roots in the iterative, incre­ ≠ Θ for most i such that 1 < i < N. mental, and evolutionary process models used as Similarly, with incremental and waterfall ap­ early as the 1950s. In addition, tools have evolved proaches, we expect a formal artifact, such as a spec­ to play a significant role in supporting TDD.
Load more

Recommended publications
  • Testing in the Software Development Life Cycle and Its Importance
    International Journal of Engineering and Information Systems (IJEAIS) ISSN: 2643-640X Vol. 3 Issue 9, September – 2019, Pages: 15-20 Testing in the Software Development Life Cycle and its Importance Noortaj Department of Computing and Technology Abasyn University Peshawar, Pakistan Email: [email protected] Abstract : Software development life cycle is a structure followed by the development team within the software organization imposed on the development of software product. The important role of testing in the software development life cycle is to improve the performance, reliability, and quality of the software. I believe testing should be thoroughly planned and conducted throughout the Software development life cycle for best results. Hence, software testing is facing different challenges. In this article, i have explained different phases of the software development life cycle, different testing techniques and its importance. Keywords: Software Development Life Cycle Testing, Testing in the Software Development Process, Software Testing, Importance of testing. 1. INTRODUCTION Testing plays an important role in the software development life-cycle to recognize the defects in the development process and resolve those defects. But before the explanation of the Software development life cycle, I would like to explain the phases of the software development process. Phase 1 Requirement collection and Analysis: For the collection of requirements a discussion is conducted to analyze the requirements and to state how the problem should be solved. The main work of the requirement collection is to determine the anticipated issues and it helps companies to finalize the necessary timeline in order to complete the work of that system in time.
    [Show full text]
  • Towards a Taxonomy of Sunit Tests *
    Towards a Taxonomy of SUnit Tests ? Markus G¨alli a Michele Lanza b Oscar Nierstrasz a aSoftware Composition Group Institut f¨urInformatik und angewandte Mathematik Universit¨atBern, Switzerland bFaculty of Informatics University of Lugano, Switzerland Abstract Although unit testing has gained popularity in recent years, the style and granularity of individual unit tests may vary wildly. This can make it difficult for a developer to understand which methods are tested by which tests, to what degree they are tested, what to take into account while refactoring code and tests, and to assess the value of an existing test. We have manually categorized the test base of an existing object-oriented system in order to derive a first taxonomy of unit tests. We have then developed some simple tools to semi-automatically categorize tests according to this taxonomy, and applied these tools to two case studies. As it turns out, the vast majority of unit tests focus on a single method, which should make it easier to associate tests more tightly to the methods under test. In this paper we motivate and present our taxonomy, we describe the results of our case studies, and we present our approach to semi-automatic unit test categorization. 1 Key words: unit testing, taxonomy, reverse engineering 1 13th International European Smalltalk Conference (ESUG 2005) http://www.esug.org/conferences/thirteenthinternationalconference2005 ? We thank St´ephane Ducasse for his helpful comments and gratefully acknowledge the financial support of the Swiss National Science Foundation for the project “Tools and Techniques for Decomposing and Composing Software” (SNF Project No.
    [Show full text]
  • 2.5 the Unit Test Framework (UTF)
    Masaryk University Faculty of Informatics C++ Unit Testing Frameworks Diploma Thesis Brno, January 2010 Miroslav Sedlák i Statement I declare that this thesis is my original work of authorship which I developed individually. I quote properly full reference to all sources I used while developing. ...…………..……… Miroslav Sedlák Acknowledgements I am grateful to RNDr. Jan Bouda, Ph.D. for his inspiration and productive discussion. I would like to thank my family and girlfriend for the encouragement they provided. Last, but not least, I would like to thank my friends Ing.Michal Bella who was very supportive in verifying the architecture of the extension of Unit Test Framework and Mgr. Irena Zigmanová who helped me with proofreading of this thesis. ii Abstract The aim of this work is to gather, clearly present and test the use of existing UTFs (CppUnit, CppUnitLite, CppUTest, CxxTest and other) and supporting tools for software project development in the programming language C++. We will compare the advantages and disadvantages of UTFs and theirs tools. Another challenge is to design effective solutions for testing by using one of the UTFs in dependence on the result of analysis. Keywords C++, Unit Test (UT), Test Framework (TF), Unit Test Framework (UTF), Test Driven Development (TDD), Refactoring, xUnit, Standard Template Library (STL), CppUnit, CppUnitLite, CppUTest Run-Time Type Information (RTTI), Graphical User Interface (GNU). iii Contents 1 Introduction ....................................................................................................................................
    [Show full text]
  • Definition of Software Construction Artefacts for Software Construction
    Chapter 3: Internet and Applications Definition of Software Construction Artefacts for Software Construction M.Zinn, G.Turetschek and A.D.Phippen Centre for Information Security and Network Research, University of Plymouth, Plymouth United Kingdom e-mail: [email protected]; [email protected], [email protected] Abstract The definition of a service based software construction process, published in 2007 (Zinn, 2007), builds on the use of software construction artefacts (SCA). These artefacts form useable building blocks (units of modelling) for software, which can be implemented in a software product by a service. The building blocks are categorized in four different types (GUI, data, function and structure). The foundation for the use of these artefacts is the method of the software construction process which constructs the software similar to the methods used in computer aided design (CAD). This paper refines and expands on the definition of the artefacts to present the current state of research in software construction procedures. It will show how the artefacts are constructed and how they can be used in software construction. In addition the software construction artefacts will be compared to components, modules and objects. Based on this definition of the application area, further potential scenarios for the use of the artefacts, as well as their properties and points still being worked on, are shown. The purpose is to create a more exact description, definition of the software construction artefacts to obtain a better understanding of the software construction process. Keywords Computer Aided Design (CAD), software construction process (SCP), software engineering, (web) services, software construction artefacts (SCA) and software construction services (SCS), model driven development (MDD) 1.
    [Show full text]
  • A Parallel Program Execution Model Supporting Modular Software Construction
    A Parallel Program Execution Model Supporting Modular Software Construction Jack B. Dennis Laboratory for Computer Science Massachusetts Institute of Technology Cambridge, MA 02139 U.S.A. [email protected] Abstract as a guide for computer system design—follows from basic requirements for supporting modular software construction. A watershed is near in the architecture of computer sys- The fundamental theme of this paper is: tems. There is overwhelming demand for systems that sup- port a universal format for computer programs and software The architecture of computer systems should components so users may benefit from their use on a wide reflect the requirements of the structure of pro- variety of computing platforms. At present this demand is grams. The programming interface provided being met by commodity microprocessors together with stan- should address software engineering issues, in dard operating system interfaces. However, current systems particular, the ability to practice the modular do not offer a standard API (application program interface) construction of software. for parallel programming, and the popular interfaces for parallel computing violate essential principles of modular The positions taken in this presentation are contrary to or component-based software construction. Moreover, mi- much conventional wisdom, so I have included a ques- croprocessor architecture is reaching the limit of what can tion/answer dialog at appropriate places to highlight points be done usefully within the framework of superscalar and of debate. We start with a discussion of the nature and VLIW processor models. The next step is to put several purpose of a program execution model. Our Parallelism processors (or the equivalent) on a single chip.
    [Show full text]
  • Enhancement in Nunit Testing Framework by Binding Logging with Unit Testing
    International Journal of Science and Research (IJSR), India Online ISSN: 2319-7064 Enhancement in Nunit Testing Framework by binding Logging with Unit testing Viraj Daxini1, D. A. Parikh2 1Gujarat Technological University, L. D. College of Engineering, Ahmedabad, Gujarat, India 2Associate Professor and Head, Department of Computer Engineering, L. D. College of Engineering, Ahmadabad, Gujarat, India Abstract: This paper describes the new testing library named log4nunit testing library which is enhanced version of nunit testing library as it is binded to logging functionality. NUnit is similar to xunit testing family in all that cases are built directly to the code of the project. Log4NUnit testing library provides the capability to log the results of tests along with testing classes. It also provides the capability to log the messages from within the testing methods. It supplies extension of NUnit’s Test class method in terms of logging the results. It has functionality to log the entity of test cases, based on the Logging framework, to document the test settings which is done at the time of testing, test case execution and it’s results. Attractive feature of new library is that it will redirect the log message to console at runtime if Log4net library is not present in the class path. It will make easy for those users who do not want to download Logging framework and put it in their class path. Log4NUnit also include a Log4net logger methods and implements utility of logging methods such as info, debug, warn, fatal etc. This work was prompted due to lack of published results concerning the implementation of Log4NUnit.
    [Show full text]
  • Object-Oriented Software Construction Oriented Software Construction Software Construction I Software Construction II
    ObjectObject--orientedoriented software construction Analysis/Requirements: What am I doing? Design: Which classes and methods? Implementation: How do I do it? Testing: Does it work? Maintenance: I just turn it in, right? Software Construction I z Programming is not just coding and debugging! z Analysis Analysis – English description of what system models, Design to meet a requirement or specification Implementation – Usually involves working with non-programmer Testing Maintenance to develop detailed specifications Waterfall model of software development z DiDesign: Mtit!Measure twice, cut once! – divide & conquer: system is composed of smaller subsystems which in turn may be composed of even smaller subsystems z OOP, system is decomposed into a set of cooperating objects – Pseudocode: describe tasks, subtasks, and how they relate – hand-simulation: desk-check pseudocode by stepping through it without using a computer – often use diagrams to better communicate the structure of the system z Often flowcharts in procedural languages and UML diagrams in OOP Wright State University, College of Engineering CS 241 Dr. T. Doom, Computer Science & Engineering Computer Programming II 58 Software Construction II z Implementation – Pick a language Analysis Design – emphasize good problem decomposition, Implementation well structured design, and readable, Testing well-documented programming style Maintenance –mayyg need to backtrack and redesign Waterfall model of software development z Testing – submitting input data or sample user interactions and seeing if program reacts properly – typically done in stages, starting with individual components and working up to subsystems, and eventually the entire program – bugs: errors in code or design – debugging: process of removing program bugs Wright State University, College of Engineering CS 241 Dr.
    [Show full text]
  • 6.005 Elements of Software Construction Fall 2008
    MIT OpenCourseWare http://ocw.mit.edu 6.005 Elements of Software Construction Fall 2008 For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms. 10/15/2008 Today’s Topics how to avoid debugging ¾assertions ¾code reviews how to do it when you have to ¾reducing test cases ¾hypothesis-driven debugging ¾binary search Debugging very hard bugs Rob Miller ¾Heisenbugs Fall 2008 © Robert Miller 2008 © Robert Miller 2008 Defensive Programming First Defense: Impossible By Design first defense against bugs is to make them impossible in the language ¾Java makes buffer overflow bugs impossible ¾automatic array bounds checking make buffer overflow bugs impossible second defense against bugs is to not make them ¾static typing eliminates many runtime type errors ¾correctness: get things riihght first time in the protocols/libraries/modules third defense is to make bugs easy to find ¾TCP/IP guarantees that data is not reordered ¾local visibility of errors: if things fail, we'd rather they fail loudly and ¾BigInteger guarantees that there will be no overflow immediately – e.g. with assertions in self-imposed conventions fourth defense is extensive testing ¾immutable objects can be passed around and shared without fear ¾uncover as many bugs as possible ¾caution: you have to keep the discipline last resort is dbidebugging • get the language to hel p you as much as possible , e.g. with pritivate and final ¾needed when effect of bug is distant from cause © Robert Miller 2008 © Robert Miller 2008 1 10/15/2008 Second Defense: Correctness Third Defense: Immediate Visibility get things right the first time if we can't prevent bugs, we can try to localize them to ¾don’t code before you think! Think before you code.
    [Show full text]
  • Integration Testing of Object-Oriented Software
    POLITECNICO DI MILANO DOTTORATO DI RICERCA IN INGEGNERIA INFORMATICA E AUTOMATICA Integration Testing of Object-Oriented Software Ph.D. Thesis of: Alessandro Orso Advisor: Prof. Mauro Pezze` Tutor: Prof. Carlo Ghezzi Supervisor of the Ph.D. Program: Prof. Carlo Ghezzi XI ciclo To my family Acknowledgments Finding the right words and the right way for expressing acknowledgments is a diffi- cult task. I hope the following will not sound as a set of ritual formulas, since I mean every single word. First of all I wish to thank professor Mauro Pezze` , for his guidance, his support, and his patience during my work. I know that “taking care” of me has been a hard work, but he only has himself to blame for my starting a Ph.D. program. A very special thank to Professor Carlo Ghezzi for his teachings, for his willingness to help me, and for allowing me to restlessly “steal” books and journals from his office. Now, I can bring them back (at least the one I remember...) Then, I wish to thank my family. I owe them a lot (and even if I don't show this very often; I know this very well). All my love goes to them. Special thanks are due to all my long time and not-so-long time friends. They are (stricty in alphabetical order): Alessandro “Pari” Parimbelli, Ambrogio “Bobo” Usuelli, Andrea “Maken” Machini, Antonio “the Awesome” Carzaniga, Dario “Pitone” Galbiati, Federico “Fede” Clonfero, Flavio “Spadone” Spada, Gianpaolo “the Red One” Cugola, Giovanni “Negroni” Denaro, Giovanni “Muscle Man” Vigna, Lorenzo “the Diver” Riva, Matteo “Prada” Pradella, Mattia “il Monga” Monga, Niels “l’e´ semper chi” Kierkegaard, Pierluigi “San Peter” Sanpietro, Sergio “Que viva Mex- ico” Silva.
    [Show full text]
  • Introduction to Unit Testing
    INTRODUCTION TO UNIT TESTING In C#, you can think of a unit as a method. You thus write a unit test by writing something that tests a method. For example, let’s say that we had the aforementioned Calculator class and that it contained an Add(int, int) method. Let’s say that you want to write some code to test that method. public class CalculatorTester { public void TestAdd() { var calculator = new Calculator(); if (calculator.Add(2, 2) == 4) Console.WriteLine("Success"); else Console.WriteLine("Failure"); } } Let’s take a look now at what some code written for an actual unit test framework (MS Test) looks like. [TestClass] public class CalculatorTests { [TestMethod] public void TestMethod1() { var calculator = new Calculator(); Assert.AreEqual(4, calculator.Add(2, 2)); } } Notice the attributes, TestClass and TestMethod. Those exist simply to tell the unit test framework to pay attention to them when executing the unit test suite. When you want to get results, you invoke the unit test runner, and it executes all methods decorated like this, compiling the results into a visually pleasing report that you can view. Let’s take a look at your top 3 unit test framework options for C#. MSTest/Visual Studio MSTest was actually the name of a command line tool for executing tests, MSTest ships with Visual Studio, so you have it right out of the box, in your IDE, without doing anything. With MSTest, getting that setup is as easy as File->New Project. Then, when you write a test, you can right click on it and execute, having your result displayed in the IDE One of the most frequent knocks on MSTest is that of performance.
    [Show full text]
  • Effective Methods for Software Testing
    Effective Methods for Software Testing Third Edition Effective Methods for Software Testing Third Edition William E. Perry Effective Methods for Software Testing, Third Edition Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2006 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN-13: 978-0-7645-9837-1 ISBN-10: 0-7645-9837-6 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 3MA/QV/QU/QW/IN No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copy- right Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no repre- sentations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fit- ness for a particular purpose. No warranty may be created or extended by sales or promo- tional materials.
    [Show full text]
  • Comparative Analysis of Junit and Testng Framework
    International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056 Volume: 05 Issue: 05 | May-2018 www.irjet.net p-ISSN: 2395-0072 Comparative Analysis of JUnit and TestNG framework Manasi Patil1, Mona Deshmukh2 Student, Dept. of MCA, VES Institute of Technology, Maharashtra, India1 Professor, Dept. of MCA, VES Institute of Technology, Maharashtra, India2 ---------------------------------------------------------------------***--------------------------------------------------------------------- Abstract - Testing is an important phase in SDLC, Testing It is flexible than Junit and supports parametrization, parallel can be manual or automated. Nowadays Automation testing is execution and data driven testing. widely used to find defects and to ensure the correctness and The Table – 1 compares different functionalities of TestNG completeness of the software. Open source framework can be and JUnit framework. used for automation testing such as Robotframework, Junit, Spock, NUnit, TestNG, Jasmin, Mocha etc. This paper compares Table -1: Functionality TestNG vs JUnit JUnit and TestNG based on their features and functionalities. Key Words: JUnit, TestNG, Automation Framework, Functionality TestNG JUnit Automation Testing, Selenium TestNG, Selenium JUnit Yes 1. INTRODUCTION Support Annotations Yes Yes Support Test Suit Initialization Yes Testing a software manually is tedious work, and takes lot of No time and efforts. Automation saves lot of time and money, Support for Tests groups Yes also it increases the test coverage
    [Show full text]