DOCSLIB.ORG

The Unit Test: Facing Cicd – Are They Elusive Definitions?

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Unit Test: Facing Cicd – Are They Elusive Definitions? THE UNIT TEST: FACING CICD – ARE THEY ELUSIVE DEFINITIONS? Journal of Information Technology Management ISSN #1042-1319 A Publication of the Association of Management THE UNIT TEST: FACING CICD – ARE THEY ELUSIVE DEFINITIONS? HADAS CHASIDIM SCE — SHAMOON COLLEGE OF ENGINEERING [email protected] DANI ALMOG SCE — SHAMOON COLLEGE OF ENGINEERING [email protected] DOV BENYOMIN SOHACHESKI SCE — SHAMOON COLLEGE OF ENGINEERING [email protected] MARK L. GILLENSON UNIVERSITY OF MEMPHIS [email protected] ROBIN POSTON UNIVERSITY OF MEMPHIS [email protected] SHLOMO MARK SCE — SHAMOON COLLEGE OF ENGINEERING [email protected] ABSTRACT The widely used term “unit test,” which is a quality procedure for testing modules of software code, has been used for decades. To enable unit testing, specialized infrastructures were designed to enable the isolation of unit tested code from its production implementation. Currently, hundreds of tools and add-ons exist for unit testing in almost every software development environment and language. Integration testing, on the other hand, which is a quality procedure for testing multiple modules of software code working together, demands a vastly different kind of infrastructure to enable the interaction of the code with other production implementation components. With the growing popularity of agile methods, the boundaries of unit and integration testing have become blurred with Continuous Integration (CI) and Continuous Deployment (CD) derived from market demand for continuous reply and reaction of the software to a rapidly changing world. CICD enhances the importance of unit testing. Following that, it is important to identify the effect of new agile software development life cycles (SDLC) on unit test activities – assuming it may affect software quality in general. In this paper, we analyze the evolving different definitions and usages of the term “unit test” and attempt to understand the implication of these definitions to the actual use of the term. Keywords: unit test, component test, unit under test Journal of Information Technology Management Volume XXIX, Number 2, 2018 40 THE UNIT TEST: FACING CICD – ARE THEY ELUSIVE DEFINITIONS? On the other hand, many people use the term “unit test” INTRODUCTION with different connotations and meanings referring to the test of a specific component or functionality. Motivation It is necessary to differentiate between the “unit Continuous Integration (CI) and Continuous under testing” and “unit test.” While unit testing is the Deployment (CD) [10] are new trends driven by market act of testing at the unit of software code, e.g., one demand. This trend is affecting the ability to provide an module, level, the term unit under test refers to the earlier and conscientious delivery of adaptation and various portions of software code that are being tested. changes to the software product. These new working The first formal definitions of “unit testing” supported by paradigms signify a different approach towards software the ANSI/IEEE Std 1008-1987, IEEE Standard for development life cycles (SDLC) and the need to Software Unit Testing reveal some flexibility concerning understand the impact of this change on software quality the meaning of the word “unit” in “unit testing,” see insert and testing procedures. The effect of the change may be below. This definition is not precise enough for today’s very significant at all dimensions of the organization and various approaches to SDLC, especially within the agile software development processes, with an examination of SDLC environments. For example, is a unit a single item its effect on unit testing being the first step. It is essential or a set of items? Moreover, the definition does not to ensure a common language among SDLC team provide us with a definite idea of the actual intention of members using the term "unit test" consistently. To model the unit definition. the CICD practices of different software industries [16], A set of one or more computer program modules the authors consider unit testing to be the basic procedure together with associated control data (for example, within the CICD approach. Following a review of the tables), usage procedures, and operating procedures that literature on CICD, research on CICD reports the satisfy the following conditions: consistent and meaningful use of unit test during the 1. All modules are from a single computer CICD process. Building on this work, this research program. explores the different definitions and usage of the term 2. At least one of the new or changed modules in "unit test" during the last ten years as reflected in the the set has not completed the unit test. academic literature. 3. The set of modules together with its associated The goal of this research study is to arrive at a data and procedures is the sole object of a better understanding of the term “unit test” and its testing process. applications. We explore the primary usages of the term Over the years, academics, open-source to see whether there are differences of opinion among participants, and the software industry have generated an leading academic researchers. To our knowledge, this is abundance of different definitions for unit tests [11]. one of the first papers that aims to better understand the While some definitions are products of necessity, others influence of current changes in software development reflect a given principle. The majority of definitions cite approaches and philosophies on testing efforts. This is principle buzzwords and concepts, attempting to remain thus an initial step in trying to arrive at a clearer accurate and authentic concerning the absolute definition understanding of the intention behind the value of unit of “unit.” Such as the case where unit tests cover only testing. functional requirements or when a unit is defined as First, we report the outcome of literature review writing many tests for one unit without actually formally research done on academic papers. The next section defining a unit. contains our definitions and suggestions to refine the The adoption of the use of xUnit tools in practice definition and use unit testing in today’s more agile is a rather straightforward process, and the administration SDLC processes. The last section concludes our findings of tests involving the use of these tools is also relatively and gives recommendations for our future research. easy. The main drawback is the misconception that such tests are categorized as unit tests. With the help of familiar testing tools, unit testing has become a Unit Testing in General chameleon that can almost imperceptibly camouflage Today, almost every programming language has itself and transform itself into other types of testing. As its individual unit testing framework (e.g., JUnit for Java, Andrew Hunter has aptly noted, “Unit tests have quickly NUnit for C#), which enables the use of small, become the proverbial hammer that makes everything automatically executable unit tests. Unit testing has look like a nail” [7]. become an accepted practice, often mandated by When codebases were still relatively small, and development processes (e.g., test-driven development). implementations were more transparent, the notion of a Journal of Information Technology Management Volume XXIX, Number 2, 2018 41 THE UNIT TEST: FACING CICD – ARE THEY ELUSIVE DEFINITIONS? unit was straightforward. Original software systems Instead of single regulatory outcomes from one unit, we delivered anywhere from a single service to a series of find ourselves imitating input from various units to services and behavior patterns. The behavior patterns conclude about a given unit. Developers find themselves were modest, and they focused on a specific goal. The uncovering the encapsulation of units and their original (still true to this the day) philosophy behind the dependencies to perform unit tests, a task that is Unix operating system (OS) is DOTADIW: “Do One tantamount to unit integration testing, a topic that is Thing and Do It Well” [13]. The entire OS was a scaffold, beyond the purview of this paper. using “very narrow, very tightly specified interfaces” [7]. Unix and Interlisp quickly gained popularity due to their Previous Surveys on Unit Tests separation of responsibilities through the use of pipes, In 2006, a unit testing practices survey [14] was filters, and interfaces [7]. performed based on focus group discussions in a software The unit can be complex in its capabilities, but it process improvement network (SPIN) and a questionnaire is intended to be solely focused on a unique output. This was employed to validate the results (shown in Table 1). characteristic transforms the unit into a black box; when it The purpose of the survey was to investigate what is provided with input, the unit will not deviate from its practitioners refer to when they talk about unit testing. established, predetermined goal. Since this survey has been conducted, more than Unit testing is the sort of testing that is usually 11 years ago, it seems logical to reexamine the use of its close to the heart of developers [18]. The primary reason terminology and practices. Programming languages, as is that, by definition, unit testing tests distinct, well- well as design implementations, have changed due to defined parts of the system in isolation from other parts. more complex software capabilities. A more recent survey Thus, they are comparatively easy to write and use. Many 2014 [5] focused on the possible test automation benefits build systems that have built-in support for unit tests, derived from the unit test: which can be leveraged without undue difficulty. With 1. What motivates developers to write unit tests? Maven [9], for example, there is a convention that The driving force behind unit testing are the describes how to write tests such that the build system can developers’ conviction and management find them, execute them, and finally prepare a report of requirements the outcome. Writing tests boils down to writing test 2.
Load more

Recommended publications
  • Core Elements of Continuous Testing
    WHITE PAPER CORE ELEMENTS OF CONTINUOUS TESTING Today’s modern development disciplines -- whether Agile, Continuous Integration (CI) or Continuous Delivery (CD) -- have completely transformed how teams develop and deliver applications. Companies that need to compete in today’s fast-paced digital economy must also transform how they test. Successful teams know the secret sauce to delivering high quality digital experiences fast is continuous testing. This paper will define continuous testing, explain what it is, why it’s important, and the core elements and tactical changes development and QA teams need to make in order to succeed at this emerging practice. TABLE OF CONTENTS 3 What is Continuous Testing? 6 Tactical Engineering Considerations 3 Why Continuous Testing? 7 Benefits of Continuous Testing 4 Core Elements of Continuous Testing WHAT IS CONTINUOUS TESTING? Continuous testing is the practice of executing automated tests throughout the software development cycle. It’s more than just automated testing; it’s applying the right level of automation at each stage in the development process. Unlike legacy testing methods that occur at the end of the development cycle, continuous testing occurs at multiple stages, including development, integration, pre-release, and in production. Continuous testing ensures that bugs are caught and fixed far earlier in the development process, improving overall quality while saving significant time and money. WHY CONTINUOUS TESTING? Continuous testing is a critical requirement for organizations that are shifting left towards CI or CD, both modern development practices that ensure faster time to market. When automated testing is coupled with a CI server, tests can instantly be kicked off with every build, and alerts with passing or failing test results can be delivered directly to the development team in real time.
    [Show full text]
  • Practical Unit Testing for Embedded Systems Part 1 PARASOFT WHITE PAPER
    Practical Unit Testing for Embedded Systems Part 1 PARASOFT WHITE PAPER Table of Contents Introduction 2 Basics of Unit Testing 2 Benefits 2 Critics 3 Practical Unit Testing in Embedded Development 3 The system under test 3 Importing uVision projects 4 Configure the C++test project for Unit Testing 6 Configure uVision project for Unit Testing 8 Configure results transmission 9 Deal with target limitations 10 Prepare test suite and first exemplary test case 12 Deploy it and collect results 12 Page 1 www.parasoft.com Introduction The idea of unit testing has been around for many years. "Test early, test often" is a mantra that concerns unit testing as well. However, in practice, not many software projects have the luxury of a decent and up-to-date unit test suite. This may change, especially for embedded systems, as the demand for delivering quality software continues to grow. International standards, like IEC-61508-3, ISO/DIS-26262, or DO-178B, demand module testing for a given functional safety level. Unit testing at the module level helps to achieve this requirement. Yet, even if functional safety is not a concern, the cost of a recall—both in terms of direct expenses and in lost credibility—justifies spending a little more time and effort to ensure that our released software does not cause any unpleasant surprises. In this article, we will show how to prepare, maintain, and benefit from setting up unit tests for a simplified simulated ASR module. We will use a Keil evaluation board MCBSTM32E with Cortex-M3 MCU, MDK-ARM with the new ULINK Pro debug and trace adapter, and Parasoft C++test Unit Testing Framework.
    [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]
  • Parallel, Cross-Platform Unit Testing for Real-Time Embedded Systems
    University of Denver Digital Commons @ DU Electronic Theses and Dissertations Graduate Studies 1-1-2017 Parallel, Cross-Platform Unit Testing for Real-Time Embedded Systems Tosapon Pankumhang University of Denver Follow this and additional works at: https://digitalcommons.du.edu/etd Part of the Computer Sciences Commons Recommended Citation Pankumhang, Tosapon, "Parallel, Cross-Platform Unit Testing for Real-Time Embedded Systems" (2017). Electronic Theses and Dissertations. 1353. https://digitalcommons.du.edu/etd/1353 This Dissertation is brought to you for free and open access by the Graduate Studies at Digital Commons @ DU. It has been accepted for inclusion in Electronic Theses and Dissertations by an authorized administrator of Digital Commons @ DU. For more information, please contact [email protected],[email protected]. PARALLEL, CROSS-PLATFORM UNIT TESTING FOR REAL-TIME EMBEDDED SYSTEMS __________ A Dissertation Presented to the Faculty of the Daniel Felix Ritchie School of Engineering and Computer Science University of Denver __________ In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy __________ by Tosapon Pankumhang August 2017 Advisor: Matthew J. Rutherford ©Copyright by Tosapon Pankumhang 2017 All Rights Reserved Author: Tosapon Pankumhang Title: PARALLEL, CROSS-PLATFORM UNIT TESTING FOR REAL-TIME EMBEDDED SYSTEMS Advisor: Matthew J. Rutherford Degree Date: August 2017 ABSTRACT Embedded systems are used in a wide variety of applications (e.g., automotive, agricultural, home security, industrial, medical, military, and aerospace) due to their small size, low-energy consumption, and the ability to control real-time peripheral devices precisely. These systems, however, are different from each other in many aspects: processors, memory size, develop applications/OS, hardware interfaces, and software loading methods.
    [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]
  • Leading Practice: Test Strategy and Approach in Agile Projects
    CA SERVICES | LEADING PRACTICE Leading Practice: Test Strategy and Approach in Agile Projects Abstract This document provides best practices on how to strategize testing CA Project and Portfolio Management (CA PPM) in an agile project. The document does not include specific test cases; the list of test cases and steps for each test case are provided in a separate document. This document should be used by the agile project team that is planning the testing activities, and by end users who perform user acceptance testing (UAT). Concepts Concept Description Test Approach Defines testing strategy, roles and responsibilities of various team members, and test types. Testing Environments Outlines which testing is carried out in which environment. Testing Automation and Tools Addresses test management and automation tools required for test execution. Risk Analysis Defines the approach for risk identification and plans to mitigate risks as well as a contingency plan. Test Planning and Execution Defines the approach to plan the test cases, test scripts, and execution. Review and Approval Lists individuals who should review, approve and sign off on test results. Test Approach The test approach defines testing strategy, roles and responsibilities of various team members, and the test types. The first step is to define the testing strategy. It should describe how and when the testing will be conducted, who will do the testing, the type of testing being conducted, features being tested, environment(s) where the testing takes place, what testing tools are used, and how are defects tracked and managed. The testing strategy should be prepared by the agile core team.
    [Show full text]
  • Unit Testing Is a Level of Software Testing Where Individual Units/ Components of a Software Are Tested. the Purpose Is to Valid
    Unit Testing is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of software. It usually has one or a few inputs and usually a single output. In procedural programming a unit may be an individual program, function, procedure, etc. In object-oriented programming, the smallest unit is a method, which may belong to a base/ super class, abstract class or derived/ child class. (Some treat a module of an application as a unit. This is to be discouraged as there will probably be many individual units within that module.) Unit testing frameworks, drivers, stubs, and mock/ fake objects are used to assist in unit testing. METHOD Unit Testing is performed by using the White Box Testing method. When is it performed? Unit Testing is the first level of testing and is performed prior to Integration Testing. BENEFITS Unit testing increases confidence in changing/ maintaining code. If good unit tests are written and if they are run every time any code is changed, we will be able to promptly catch any defects introduced due to the change. Also, if codes are already made less interdependent to make unit testing possible, the unintended impact of changes to any code is less. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test.
    [Show full text]
  • Including Jquery Is Not an Answer! - Design, Techniques and Tools for Larger JS Apps
    Including jQuery is not an answer! - Design, techniques and tools for larger JS apps Trifork A/S, Headquarters Margrethepladsen 4, DK-8000 Århus C, Denmark [email protected] Karl Krukow http://www.trifork.com Trifork Geek Night March 15st, 2011, Trifork, Aarhus What is the question, then? Does your JavaScript look like this? 2 3 What about your server side code? 4 5 Non-functional requirements for the Server-side . Maintainability and extensibility . Technical quality – e.g. modularity, reuse, separation of concerns – automated testing – continuous integration/deployment – Tool support (static analysis, compilers, IDEs) . Productivity . Performant . Appropriate architecture and design . … 6 Why so different? . “Front-end” programming isn't 'real' programming? . JavaScript isn't a 'real' language? – Browsers are impossible... That's just the way it is... The problem is only going to get worse! ● JS apps will get larger and more complex. ● More logic and computation on the client. ● HTML5 and mobile web will require more programming. ● We have to test and maintain these apps. ● We will have harder requirements for performance (e.g. mobile). 7 8 NO Including jQuery is NOT an answer to these problems. (Neither is any other js library) You need to do more. 9 Improving quality on client side code . The goal of this talk is to motivate and help you improve the technical quality of your JavaScript projects . Three main points. To improve non-functional quality: – you need to understand the language and host APIs. – you need design, structure and file-organization as much (or even more) for JavaScript as you do in other languages, e.g.
    [Show full text]
  • Testing and Debugging Tools for Reproducible Research
    Testing and debugging Tools for Reproducible Research Karl Broman Biostatistics & Medical Informatics, UW–Madison kbroman.org github.com/kbroman @kwbroman Course web: kbroman.org/Tools4RR We spend a lot of time debugging. We’d spend a lot less time if we tested our code properly. We want to get the right answers. We can’t be sure that we’ve done so without testing our code. Set up a formal testing system, so that you can be confident in your code, and so that problems are identified and corrected early. Even with a careful testing system, you’ll still spend time debugging. Debugging can be frustrating, but the right tools and skills can speed the process. "I tried it, and it worked." 2 This is about the limit of most programmers’ testing efforts. But: Does it still work? Can you reproduce what you did? With what variety of inputs did you try? "It's not that we don't test our code, it's that we don't store our tests so they can be re-run automatically." – Hadley Wickham R Journal 3(1):5–10, 2011 3 This is from Hadley’s paper about his testthat package. Types of tests ▶ Check inputs – Stop if the inputs aren't as expected. ▶ Unit tests – For each small function: does it give the right results in specific cases? ▶ Integration tests – Check that larger multi-function tasks are working. ▶ Regression tests – Compare output to saved results, to check that things that worked continue working. 4 Your first line of defense should be to include checks of the inputs to a function: If they don’t meet your specifications, you should issue an error or warning.
    [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]
  • Agile Test Automation Strategy for Anyone and Everyone!
    Agile Test Automation Strategy For Anyone and Everyone! Gerard Meszaros [email protected] Much Ado About Agile 2011 1 Copyright 2011 Gerard Meszaros My Background •Software developer 80’s •Development manager Embedded •Project Manager ----- Telecom •Software architect 90’s •OOA/OOD Mentor •Requirements (Use Case) Mentor ----- I.T. •XP/TDD Mentor •Agile PM Mentor 00’s •Test Automation Consultant & Trainer Gerard Meszaros •Lean/Agile Coach/Consultant [email protected] Product & I.T. Much Ado About Agile 2011 2 Copyright 2011 Gerard Meszaros Agenda • Motivation – The Agile Test Problem – The Fragile Test Problem • Approaches to Test AutomationRough timings for Agile Test Automation Strategy Time per slide: 1.4 # of Slide # • Test Automation Strategy # Topic Time Slides Start End Motivation 11.2 8 2 9 Exercise 1 - Automation Motivation 10 1 10 10 Intro to Automation 7 5 11 15 Exercise 2 - Why not Record & Playback? 10 1 16 16 Why Automated Tests are Fragile 8.4 6 17 22 How Agile Automation Changes Things 9.8 7 24 30 Intro to Example-Driven Development 7 5 32 36 Managing Scope vs Detail in Examples 15.4 11 38 48 How to specify workflows 8.4 6 50 55 Exercise 3 - Workflow Tests (Keyword-Driven) 15 1 56 56 Using Data-Driven Tests to specify business rules 8.4 6 55 60 Exercise 4 - Business Rules Test (Data-Driven) 15 1 61 61 How Tests Interact With the SUT 7 5 62 66 Test-Driven Architecture 5.6 4 67 70 Legacy Systems (if time permits) 19.6 14 71 84 The Role of Unit Tests 8.4 6 85 90 Test Automation Strategy 14 10 91 100 180.2 97 Much
    [Show full text]
  • Test Script Debugger CBTA 3.0 SP11 Document History
    Test Automation - User Guide PUBLIC SAP Solution Manager 7.2 2018-12-03 CBTA - Test Script Debugger CBTA 3.0 SP11 Document History Version Date Change 1.6 2018-12-03 CBTA 3.0 SP11 Update 1.5 2018-05-15 CBTA 3.0 SP10 Update 1.4 2017-09-30 CBTA 3.0 SP9 Update 1.3 2017-03-01 CBTA 3.0 SP8 Update 1.2 2014-05-27 CBTA 3.0 SP2 Update CBTA - Test Script Debugger 2 Document History Table of Contents 1 Running a CBTA Test Script in Debug Mode..........................................................................4 2 How-to start .............................................................................................................................5 2.1 Add or remove breakpoint..................................................................................................................................... 8 2.2 Step Over............................................................................................................................................................ 9 2.3 Run...................................................................................................................................................................... 9 2.4 Stop Debugger................................................................................................................................................... 9 2.5 Error Behavior .......................................................................................................................................................10 2.6 Dynamic Report...............................................................................................................................................
    [Show full text]