DOCSLIB.ORG

Squish Coco 5.1.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Squish Coco 5.1.0 Squish Coco 5.1.0 Copyright © 2003–2011 Sébastien Fricker, 2011–2021 froglogic GmbH CONTENTS Contents I Overview2 1 Squish Coco – A code coverage tool for Tcl, QML, C# and C/C++3 1.1 CoverageScanner – Instrumentation as part of the build process...................4 1.2 CoverageBrowser – Viewing, analyzing and managing code coverage results.............5 II Setup and Tutorials7 2 Installation and Setup 8 2.1 Choosing a license...........................................8 2.2 Installation...............................................9 2.2.1 Installation of a license server.................................9 2.2.2 Running the license server................................... 10 2.3 Updates................................................. 10 3 Instrumentation of a simple project 11 3.1 UNIX and macOS setup........................................ 11 3.1.1 Setup.............................................. 11 3.1.2 Structure of the parser directories.............................. 12 3.1.3 Compiling and testing..................................... 12 3.1.4 Instrumentation......................................... 13 3.1.5 How the project is instrumented................................ 13 3.1.6 Additional changes....................................... 14 3.2 Microsoft Windows setup........................................ 15 3.2.1 Setup.............................................. 15 3.2.2 Structure of the parser directories.............................. 15 3.2.3 Compiling and testing..................................... 15 3.2.4 Instrumentation......................................... 16 Squish Coco 5.1.0 - i - froglogic GmbH CONTENTS 3.2.5 How the project is instrumented................................ 17 3.2.6 Additional changes....................................... 18 3.3 Beyond the minimal instrumentation.................................. 18 3.3.1 Excluding code from instrumentation............................. 18 3.3.2 Making the test names visible................................. 19 3.3.3 Patch file analysis........................................ 19 3.3.4 The patch analysis report.................................... 20 3.3.5 Reverse patches......................................... 21 3.3.6 Bug location.......................................... 21 3.3.7 The function profiler...................................... 23 3.4 Using the function profiler for performance improvents........................ 26 3.4.1 Application Building...................................... 26 3.4.2 Analyzing the Performance Issues............................... 27 4 Code coverage for a Qt application 31 4.1 Compiling the example application................................... 31 4.1.1 The first code coverage results................................. 33 4.1.2 Interactive testing........................................ 34 4.1.3 Writing unit tests........................................ 36 4.2 Working with code coverage data.................................... 41 4.2.1 Post mortem analysis...................................... 42 4.2.2 Evaluating the impact of a hot fix............................... 43 4.2.3 Black-box testing/distributed testing.............................. 44 4.2.4 Verifying if a bug fix is correctly tested............................ 45 4.3 Conclusion............................................... 46 III About Code Coverage 48 5 Squish Coco’s code coverage analysis 49 5.1 Coverage metrics supported by Squish Coco .............................. 49 5.1.1 Coverage metrics and safety standards............................. 50 5.2 Description of the coverage metrics.................................. 51 5.2.1 Statement Block Coverage................................... 51 5.2.2 Decision Coverage....................................... 52 5.2.3 Condition Coverage...................................... 53 Squish Coco 5.1.0 - ii - froglogic GmbH CONTENTS 5.2.4 Multiple Condition Coverage.................................. 54 5.2.5 MC/DC............................................. 55 5.3 Display of the results.......................................... 57 5.4 Performance............................................... 58 5.5 Statistics................................................. 58 5.6 Problems with line coverage...................................... 61 6 Testing Methodologies 63 6.1 Hit vs Count............................................... 63 6.2 Strategies................................................ 63 6.2.1 Manual tests.......................................... 64 6.2.2 Black box tests......................................... 64 6.2.3 Unit Tests............................................ 64 6.2.4 Automatic Tests........................................ 65 7 Code metrics 66 7.1 eLOC.................................................. 66 7.2 McCabe................................................. 66 7.2.1 Definition............................................ 66 7.2.2 Properties............................................ 67 7.2.3 eLOC vs McCabe – Which metric to choose?......................... 67 7.2.4 Variants of McCabe metrics.................................. 67 7.2.4.1 McCabe with cases grouped............................. 68 7.2.4.2 McCabe with condensed switches.......................... 68 IV CoverageScanner Reference 69 8 Introduction 70 8.1 Invoking CoverageScanner ....................................... 70 9 Command Line Arguments 72 9.1 Environment variables......................................... 72 9.2 List of options.............................................. 73 9.2.1 Coverage methods....................................... 73 9.2.2 Fine-tuning of the instrumentation............................... 74 9.2.3 File and path inclusion..................................... 76 Squish Coco 5.1.0 - iii - froglogic GmbH CONTENTS 9.2.4 Function inclusion....................................... 78 9.2.5 Debugging........................................... 79 9.2.6 Execution report........................................ 79 9.2.7 Command line modification.................................. 81 9.2.8 Generated code......................................... 81 9.2.9 Miscellaneous......................................... 83 9.3 Instrumenting using preprocessor symbols............................... 84 9.4 Regular Expressions.......................................... 84 10 Library calls 86 10.1 C and C++ Library........................................... 86 10.1.1 __coveragescanner_install() ............................... 86 10.1.2 __coveragescanner_testname() .............................. 87 10.1.3 __coveragescanner_teststate() ............................. 87 10.1.4 __coveragescanner_add_html_comment() ......................... 88 10.1.5 __coveragescanner_clear_html_comment() ....................... 88 10.1.6 __coveragescanner_save() ................................ 88 10.1.7 __coveragescanner_clear() ................................ 88 10.1.8 __coveragescanner_filename() .............................. 89 10.1.9 __coveragescanner_get_filename() ........................... 89 10.1.10 __coveragescanner_register_library() ......................... 89 10.1.11 __coveragescanner_unregister_library() ....................... 90 10.1.12 __coveragescanner_register_squish() ......................... 90 10.1.13 __coveragescanner_set_custom_io() ........................... 91 10.2 C# Library................................................ 92 10.2.1 CoverageScanner.__coveragescanner_init() ...................... 92 10.2.2 CoverageScanner.__coveragescanner_testname() ................... 92 10.2.3 CoverageScanner.__coveragescanner_teststate() .................. 92 10.2.4 CoverageScanner.__coveragescanner_memory_pool_stat() .............. 93 10.2.5 CoverageScanner.__coveragescanner_add_html_comment() .............. 93 10.2.6 CoverageScanner.__coveragescanner_clear_html_comment() ............ 93 10.2.7 CoverageScanner.__coveragescanner_save() ...................... 93 10.2.8 CoverageScanner.__coveragescanner_clear() ..................... 94 10.2.9 CoverageScanner.__coveragescanner_filename() ................... 94 Squish Coco 5.1.0 - iv - froglogic GmbH CONTENTS 10.2.10 CoverageScanner.__coveragescanner_set_custom_io() ................ 94 11 Controlling the instrumentation from the source code 96 11.1 Annotations............................................... 96 11.1.1 Comments........................................... 96 11.1.2 Manual Validation....................................... 97 11.2 C and C++ Pragmas........................................... 98 11.3 C# regions................................................ 99 V QML Coverage 101 12 QML coverage 102 12.1 Setup.................................................. 102 12.1.1 Compilation of the plugin................................... 102 12.2 Use of CocoQML............................................ 103 12.2.1 Instrumentation......................................... 103 12.2.2 Measuring the coverage.................................... 103 12.3 Reference................................................ 104 12.3.1 cocoqmlscanner ........................................ 104 12.3.2 The tracker plugin....................................... 104 13 QML coverage with a library 106 13.1 Overview................................................ 106 13.2 Installation............................................... 106 13.2.1 General remark......................................... 107 13.2.2 Finding the right version of the archive............................ 107 13.2.3 Linux™ installation......................................
Load more

Recommended publications
  • Practical Example of Tcl Command Design in a Qt/C++ Graphical Application Tony Johnson October 18Th, 2017 Tony [email protected]
    Practical Example of Tcl Command Design in a Qt/C++ Graphical Application Tony Johnson October 18th, 2017 [email protected] Abstract Tcl provides excellent support for creating complicated user commands in applications that have correct-by-construction built-in help, support for hidden commands, support for position- independent switches, and more. This paper discusses the technical details for how we created one such command in our Qt-based application. Summary In this paper I will discuss the technical details around the design for the Tcl “wave” command in our Qt-based [1] application. Visualizer is a GUI for displaying and analyzing simulation waveforms. It is driven by the user either via standard GUI operations such as menu selections, button clicks, drag and drop, key accelerators, etc or via commands passed in through a command prompt which is a Tcl shell. Because GUI operations are inherently difficult to automate among other reasons, there was a strong need to have a command for our waveform window that could do everything that could be done via the GUI. Since we already had a Tcl shell in our application, the obvious answer was to create a Tcl command to provide this capability. Luckily Tcl is well suited for implementing such a complex command. Background and Motivation Command-based control of graphical user interface interactions is important for many different reasons. The four key reasons that motivated this work were: Testing; User Control; 3rd Party Access; Save/Restore; and Expandability. Testing Unless you want to retest the GUI operations in your application by hand with every major release, minor release, feature addition and bug fix (trust me, you don’t), then you will want to have some way to create automated tests for GUI interactions.
    [Show full text]
  • Scons API Docs Version 4.2
    SCons API Docs version 4.2 SCons Project July 31, 2021 Contents SCons Project API Documentation 1 SCons package 1 Module contents 1 Subpackages 1 SCons.Node package 1 Submodules 1 SCons.Node.Alias module 1 SCons.Node.FS module 9 SCons.Node.Python module 68 Module contents 76 SCons.Platform package 85 Submodules 85 SCons.Platform.aix module 85 SCons.Platform.cygwin module 85 SCons.Platform.darwin module 86 SCons.Platform.hpux module 86 SCons.Platform.irix module 86 SCons.Platform.mingw module 86 SCons.Platform.os2 module 86 SCons.Platform.posix module 86 SCons.Platform.sunos module 86 SCons.Platform.virtualenv module 87 SCons.Platform.win32 module 87 Module contents 87 SCons.Scanner package 89 Submodules 89 SCons.Scanner.C module 89 SCons.Scanner.D module 93 SCons.Scanner.Dir module 93 SCons.Scanner.Fortran module 94 SCons.Scanner.IDL module 94 SCons.Scanner.LaTeX module 94 SCons.Scanner.Prog module 96 SCons.Scanner.RC module 96 SCons.Scanner.SWIG module 96 Module contents 96 SCons.Script package 99 Submodules 99 SCons.Script.Interactive module 99 SCons.Script.Main module 101 SCons.Script.SConsOptions module 108 SCons.Script.SConscript module 115 Module contents 122 SCons.Tool package 123 Module contents 123 SCons.Variables package 125 Submodules 125 SCons.Variables.BoolVariable module 125 SCons.Variables.EnumVariable module 125 SCons.Variables.ListVariable module 126 SCons.Variables.PackageVariable module 126 SCons.Variables.PathVariable module 127 Module contents 127 SCons.compat package 129 Module contents 129 Submodules 129 SCons.Action
    [Show full text]
  • Squish Coco 3.3.2 - Copyright ©2015 Froglogic Gmbh CONTENTS
    Squish Coco 3.3.2 - Copyright ©2015 froglogic GmbH CONTENTS Contents 1 Introduction 1 1.1 Squish Coco - Code Coverage Tool for Tcl, C# and C/C++ . .1 1.2 CoverageScanner—Instrumentation during the Generation . .2 1.3 CoverageBrowser—View, Analyse, and Manage, Code Coverage Results . .2 I Quick Start and Tutorials 4 2 Synopsis 5 3 Using Squish Coco 6 4 Creating an instrumented project 7 4.1 Installing Squish Coco ..............................................7 4.2 C++ on Microsoft Visual Studio using the Microsoft Visual Studio Add-in . .7 4.3 C# on Microsoft Visual Studio . .8 4.4 Tcl.........................................................9 4.4.1 Using more than one Tcl version on one system . 10 4.5 Command Line Tools . 10 5 Generating Instrumentations Without Modifying Projects 12 5.1 GNU Make . 12 5.2 Microsoft NMake . 12 5.3 Microsoft Visual Studio . 13 5.4 Microsoft MSBuild . 13 5.5 Mono C# XBuild . 13 6 Instrumenting a simple project 14 6.1 UNIX and Apple Mac OS X setup . 14 6.1.1 Setup . 14 6.1.2 Structure of the parser directories . 15 6.1.3 Compiling and testing . 15 6.1.4 Instrumentation . 15 - i - froglogic GmbH CONTENTS 6.1.5 How the project is instrumented . 16 6.1.6 Additional changes . 17 6.2 Microsoft Windows setup . 17 6.2.1 Setup . 17 6.2.2 Structure of the parser directories . 17 6.2.3 Compiling and testing . 18 6.2.4 Instrumentation . 18 6.2.5 How the project is instrumented . 19 6.2.6 Additional changes .
    [Show full text]
  • Life After Make - Building Software with Scons
    Life after Make - Building Software with SCons Joe VanAndel NCAR Atmospheric Technology Division Research Technology Facility November 20, 2003 SCons Slide 1 of 36 Audience survey • Do you enjoy using autoconf and make? (or do you just tolerate them!) • How frequently do you run “ make clean” - just to be safe! • What alternatives have you tried? November 20, 2003 SCons Slide 2 of 36 What's wrong with Make(1) • No built-in dependency tools • Quirky syntax – tabs matter – can't cut/paste text from makefiles! • Another “ little language” to learn. • Uses shell to extend Make's capabilities (shell is an awful programming language!) November 20, 2003 SCons Slide 3 of 36 include/linux/version.h: ./Makefile @expr length "$(KERNELRELEASE)" \<= $(uts_len) > /dev/null || \ (echo KERNELRELEASE \"$(KERNELRELEASE)\" exceeds $(uts_len) characters >&2; false) @echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" > .ver @echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` >> .ver @echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' >>.ver @mv -f .ver $@ November 20, 2003 SCons Slide 4 of 36 What's Wrong with Make(2) • Dependence on timestamps – – Clock skew in networked development systems – Fooled by restoring old source files • Make doesn't know that changing compiler flags builds different object files – Debug flags (-g) – Optimize flags (-02) – Pre-processor definitions (-DDEBUG_THIS) November 20, 2003 SCons Slide 5 of 36 What's Wrong with make(3) • Hard to build multi-directory projects
    [Show full text]
  • Analysis of Domain Specific Languages for GUI Testing: Rspec and Cucumber for Sikuli
    Journal of Multidisciplinary Engineering Science and Technology (JMEST) ISSN: 3159-0040 Vol. 2 Issue 1, January - 2015 Analysis of Domain Specific Languages for GUI testing: RSpec and Cucumber for Sikuli Ivan Evgrafov, [email protected] Raimund Hocke Roman S. Samarev, [email protected] Head Developer of SikuliX, Elena V. Smirnova, [email protected] [email protected], Nidderau, Germany Bauman Moscow State Technical University, Russia Abstract – This article is devoted to new usage tions. Little languages are small DSLs that do not include of the domain specific languages (DSL) for software many features found in General Purpose Programming with a Graphical User Interfaces (GUI) testing. This languages (GPLs). The testers use the GPPL in case if paper’s authors are a developers of the enhanced there is no time to create special DSL - in case of the short software Sikulix, the product which targeted for the term software project or if they could not find a proper programs with graphical interface testing. They pro- DSL, or if they could not create their own DSL. And they pose it as a functional basis for DSL. The SikuliX is use a domain-specific language (DSL), a computer lan- considering as an environment for domain specific guage specialized to a particular application domain in languages (DSL and DSEL). The results of two spe- such a case [17]. This is in contrast to a general-purpose cialized testing DSL’s estimation are being presented language (GPPL), which is broadly applicable across do- in this paper: the frameworks Rspec which belongs mains, and lacks specialized features for a particular do- to a Domain Specific Embedded Language (DSEL) main.
    [Show full text]
  • The WAF Build System
    The WAF build system The WAF build system Sebastian Jeltsch Electronic Vision(s) Kirchhoff Institute for Physics Ruprecht-Karls-Universität Heidelberg 31. August 2010 Sebastian Jeltsch The WAF build system 31. August 2010 1 / 19 The WAF build system Introduction WorkBuildflow Sebastian Jeltsch The WAF build system 31. August 2010 2 / 19 make = major pain What we expect from our build system: flexibility integration of existing workflows access to well established libraries extensibility power usability The WAF build system Introduction WorkBuildflow For us: low-level code many many layers Sebastian Jeltsch The WAF build system 31. August 2010 3 / 19 What we expect from our build system: flexibility integration of existing workflows access to well established libraries extensibility power usability The WAF build system Introduction WorkBuildflow For us: low-level code many many layers make = major pain Sebastian Jeltsch The WAF build system 31. August 2010 3 / 19 The WAF build system Introduction WorkBuildflow For us: low-level code many many layers make = major pain What we expect from our build system: flexibility integration of existing workflows access to well established libraries extensibility power usability Sebastian Jeltsch The WAF build system 31. August 2010 3 / 19 The WAF build system Introduction Autotools (GNU Build System) GNU Build System + few dependencies on user side (shell scripts) developer autoscan ed + generates standard make files + widely used configure.ac Makefile.am – platform dependent (bash aclocal autoheader automake scripts) aclocal.m4 config.h.in Makefile.in – autoconf-configure is slow autoconf Often: tconfigure >> tmake. – another scripting language configure Makefile make user Sebastian Jeltsch The WAF build system 31.
    [Show full text]
  • Iotivity and Iotivity-Lite • Resources for Getting Started
    Overview of IoTivity Projects Kishen Maloor, Intel June 2018 Agenda • What is IoTivity? • Structure of an OCF implementation • IoTivity and IoTivity-Lite • Resources for getting started 2 What is IoTivity? • Umbrella of projects for building IoT devices • Open-source, reference implementations of OCF specifications • Serve as starting point for developing and certifying OCF products Specifications Vertical Data Models Device Certification Strategy, Marketing Independent governance with coordinated efforts 3 Structure of an OCF implementation User space IoT Applications Outer functional blocks APIs & Language Security Manage on-boarding, Bindings Provisioning Provisioning credentials, Infrastructure Access-control lists OCF Resource Model Resource directory, Device High-level Services Wi-Fi Easy Setup, etc. Stack Security Flows Bridging to other Zigbee, Z-Wave, etc. IP Connectivity ecosystems Kernel space Network Interfaces OS & Kernel 4 IoTivity and IoTivity-Lite • IoTivity • Suitable only for more capable device classes • Runs on Linux, Windows, Android, macOS • Multiple language bindings: C, C++, Java, Node.js • IoTivity-Lite (formerly called IoTivity-Constrained) • Lightweight implementation of OCF specifications • Suitable for all device classes (including few constrained devices) • Runs on Linux, Windows, macOS, and multiple RTOSes • C APIs only 5 IoTivity Directory Structure auto_build.py NOTICE.md auto_build.sh plugins bridging prep.sh build_common README-building-and-running-remote-access-sample.txt cloud README.md CONTRIBUTING.md
    [Show full text]
  • Empirical Comparison of Scons and GNU Make
    Großer Beleg Empirical Comparison of SCons and GNU Make Ludwig Hähne August 21, 2008 Technical University Dresden Department of Computer Science Institute for System Architecture Chair for Operating Systems Professor: Prof. Dr. rer. nat. Hermann Härtig Tutor: Dipl.-Inf. Norman Feske Dipl.-Inf. Christian Helmuth Erklärung Hiermit erkläre ich, dass ich diese Arbeit selbstständig erstellt und keine anderen als die angegebenen Hilfsmittel benutzt habe. Dresden, den 26. Juni 2008 Ludwig Hähne Abstract Build systems are an integral part of every software developer’s tool kit. Next to the well-known Make build system, numerous alternative solutions emerged during the last decade. Even though the new systems introduced superior concepts like content signa- tures and promise to provide better build accuracy, Make is still the de facto standard. This paper examines GNU Make and SCons as representatives of two conceptually distinct approaches to conduct software builds. General build-system concepts and their respective realizations are discussed. The performance and scalability are empirically evaluated by confronting the two competitors with comparable real and synthetic build tasks. V Contents 1 Introduction 1 2 Background 3 2.1 Design Goals . .3 2.1.1 Convenience . .3 2.1.2 Correctness . .3 2.1.3 Performance . .3 2.1.4 Scalability . .4 2.2 Software Rebuilding . .4 2.2.1 Dependency analysis . .4 2.2.1.1 File signatures . .4 2.2.1.2 Fine grained dependencies . .5 2.2.1.3 Dependency declaration . .5 2.2.1.4 Dependency types . .5 2.2.2 Build infrastructure . .6 2.2.3 Command scheduling . .6 2.3 Build System Features .
    [Show full text]
  • Squish for Java Data Sheet
    Home: www.froglogic.com E-Mail: [email protected] Evaluation: www.froglogic.com/evaluate ...one leap ahead Squish® for Java® DATA SHEET Functional GUI testing is a vital part of the development and QA process of today©s complex GUI applications. Manually testing the GUI of an application is error-prone, unreliable, unpredictable and slow. Automating this process on the other hand, allows to reliably deliver results quickly, enabling developers to find and fix regressions in nearly no time. This does not only save time but also money. Squish for Java is the most powerful automated GUI testing tool for Java™ Swing/AWT, SWT and Eclipse® Rich Client Platform (RCP) applications. Squish for Java offers dedicated support and tight integration for these GUI toolkits. Using the comfortable Squish IDE, tests are created using Squish©s event recorder. Verification and synchronization points can be easily inserted. Squish allows the user to choose between popular and open scripting languages such as Python, JavaScript, Perl and Tcl for test scripts. Therefore the complete set of language features, in addition to Squish©s test-specific APIs can be used to create powerful and robust tests. Squish for Java recognizes all standard Java GUI controls and offers special support for complex widgets such as tree-, table-, list and menu controls. In addition Squish for Java recognizes custom Java controls. Squish for Java©s mechanism to identify Java GUI widgets is very robust to make sure Squish tests will keep working while the application evolves. Squish for Java provides access to the complete Java API via its test scripting languages and offers access to all objects and properties via the Spy and verification point editor.
    [Show full text]
  • Scons User Guide 0.96.91
    SCons User Guide 0.96.91 Steven Knight SCons User Guide 0.96.91 by Steven Knight Revision 0.96.91.D001 (2005/09/08 09:14:36) Edition Published 2004 Copyright © 2004 Steven Knight SCons User’s Guide Copyright (c) 2004 Steven Knight Table of Contents Preface..................................................................................................................................... i SCons Principles ........................................................................................................... i A Caveat About This Guide’s Completeness........................................................... i Acknowledgements .................................................................................................... ii Contact.......................................................................................................................... ii 1. Building and Installing SCons........................................................................................1 Installing Python ..........................................................................................................1 Installing SCons From Pre-Built Packages................................................................1 Installing SCons on Red Hat (and Other RPM-based) Linux Systems .......1 Installing SCons on Debian Linux Systems ....................................................2 Installing SCons on Windows Systems............................................................2 Building and Installing SCons on Any System ........................................................2
    [Show full text]
  • Jumpstart for Squish Datasheet
    Jumpstart for Squish Accelerate the Use of Squish Within Your QA Team Your acquisition of froglogic’s Squish® software product Optional Add-ons was the first step in creating a cost effective approach to Depending on your needs and staffing, ICS offers testing your Qt® based applications. The next step is for optional extensions to this program: your team to learn quickly how to use Squish in your en- vironment. ICS has developed Jumpstart for Squish for Extension of Test Infrastructure: ICS recommends organizations that are under tight deadlines and that the test scripts and test results be placed under cannot wait for the natural development of internal configuration management, and that you start with experts. By purchasing the Jumpstart for Squish service, overnight batch runs of your regression tests. As part of ICS experts will educate your team on the best practices this phase, ICS will help you publish the results of your in using Squish and help you get started immediately. nightly test runs on an internal web server for manageri- This Jumpstart will shave off weeks of trial and error and al review of test results. false starts. It is the best way to get started now, and get started right. Development of Initial Smoke Tests: We will work with your team to develop an initial set of smoke tests The Jumpstart for Squish is a 5-day engagement that that can be used immediately to validate the proper includes formal training installation, infrastructure functioning of your application. These initial tests will development, and test creation by ICS experts.
    [Show full text]
  • Froglogic Slidedeck
    Behavior Driven Development and Testing of Qt and QML applications Qt Developer Days 2014 by Reginald Stadlbauer About me . Name: Reginald Stadlbauer . Company: froglogic GmbH . Position: co-founder and CEO . Worked as Software Engineer at Trolltech and the KDE project About froglogic . HQ: Hamburg . Founded: 2003 . US presence since 2008 . Product focus on Squish - Squish GUI Tester (Cross-Platform/Cross-Technology GUI Test Automation) - Squish Coco (C, C++ and C# Code Coverage) . More than 3.000 customers world-wide Overview . What is BDD and TDD . Automating a Behavior Driven Test . Live Demo & Conclusion What is BDD / BDT? “BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.” - Dan North http://en.wikipedia.org/wiki/Behavior-driven_development OR... What is BDD / BDT? . Based on Test Driven Development - Write (failing) test - Implement feature until test passes - Unit-Test level granularity (inside-out) . But - Focus on application's behavior and specification - Description in a human-readable DSL (e.g. Gherkin) - Less focus on implementation details Versatile usage of Feature Files . User story / feature specification . Communicate with customer / users . Documentation of acceptance test . Sequence to walk through for manual tests . Storyboard for automation of tests Why BDD/BDT . “Test first” development on a higher level . Clearly
    [Show full text]