DOCSLIB.ORG

Testing Strategies F

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Testing Strategies F M. Weintraub and TESTING STRATEGIES F. Tip Thanks go to Andreas Zeller for allowing incorporation of his materials TESTING Testing: a procedure intended to establish the quality, performance, or reliability of something, esp. before it is taken into widespread use. 2 SOFTWARE TESTING Software Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user. 3 TECHNIQUES FOR EVALUATING SOFTWARE Testing Program (dynamic Analysis verification) (static or dynamic) Inspections Proofs (static verification) (static verification) THE CURSE OF TESTING Dijkstra’ Curse: Testing can show the presence but not the absence of errors optimistic inaccuracy a test run a test a test run a test run a test a test run a test ∞ possible runs 5 STATIC ANALYSIS We cannot tell whether this condition ever if ( .... ) { holds ... Zeller’s Corollary:(halting problem) Static Analysis lock(S); can confirm the absence but not } Static pessimistic checking for ... the presence of errorsinaccuracy if ( ... ) { match is ... necessarily inaccurate unlock(S); } 6 COMBINING METHODS a proof a proof a test run a test unverified a test run a test run a test run a test abstraction properties ∞ possible runs 7 WHY IS SOFTWARE VERIFICATION HARD? 1. Many different quality requirements 2. Evolving (and deteriorating) structure 3. Inherent non-linearity 4. Uneven distribution of faults 8 WHY IS SOFTWARE VERIFICATION HARD? 1. Many different quality requirements 2. Evolving (and deteriorating) structure 3. Inherent non-linearity 4. Uneven distribution of faults If an elevator can safely carry a load of 1000 kg, it can also safely carry any smaller load 9 WHY IS SOFTWARE VERIFICATION HARD? 1. Many different quality requirements 2. Evolving (and deteriorating) structure 3. Inherent non-linearity 4. Uneven distribution of faults If an elevator can safely carry a load of If a procedure correctly sorts a set of 256 1000 kg, it can also safely carry any smaller elements, it may fail on a set of 255 or 53 load elements, as well as on 257 or 1023 10 TRADE-OFFS We can be inaccurate (optimistic or pessimistic) or we can simplify properties… but you cannot have it all! 11 RECALL THE WATERFALL MODEL (1968) Communication project initiation requirements gathering Planning estimating scheduling tracking Modeling analysis design Construction code test Deployment delivery support feedback TESTING FALLS TOWARD THE END… Communication project initiation requirements gathering Planning estimating scheduling tracking Modeling analysis design Construction code test Deployment delivery support feedback WE TEND TO ASSUME OUR CODE IS DONE WHEN 14 WE TEND TO ASSUME OUR CODE IS DONE WHEN We built it! 15 BUT, SHALL WE DEPLOY IT? Is it really ready for release? 16 SO LET’S FOCUS ON THE CONSTRUCTION STEP Construction code test Waterfall Model (1968) Construction code test Deployment delivery support feedback V & V: VALIDATION & VERIFICATION Validation Verification Ensuring that software has been built Ensuring that software correctly according to customer requirements implements a specific function Are we building the Are we building the right product? product right? 19 VALIDATION AND VERIFICATION SW Specs System Actual Requirements Validation Verification Involves usability testing, user Includes testing, code feedback, & product trials inspections, static analysis, proofs 20 VALIDATION if a user presses a request button at floor i, an available elevator must arrive at floor i soon not verifiable, but may be validated 21 VERIFICATION if a user presses a request button at floor i, an available elevator must arrive at floor i within 30 seconds verifiable 2 2 CORE QUESTIONS 1. When does V&V start? When is it done? 2. Which techniques should be applied? 3. How do we know a product is ready? 4. How can we control the quality of successive releases? 5. How can we improve development? 23 WHEN DOES V&V START? WHEN IS IT DONE? WATERFALL SEPARATES CODING AND TESTING INTO TWO ACTIVITIES Code Test FIRST CODE, THEN TEST 1. Developers on software should do no testing at all 2. Software should be “tossed over a wall” to strangers who will test it mercilessly 3. Testers should get involved with the project only when testing is about to begin 26 V MODEL Module Test From: Pezze + Young, “Software Testing and Analysis” 27 UNIT TESTS Aims to uncover errors at module boundaries Typically written by programmer Should be completely automatic (→ regression testing) 28 TESTING COMPONENTS: STUBS AND DRIVERS Driver A driver exercises a module’s functions A stub simulates not-yet-ready modules Frequently realized as mock objects Stub Stub 29 PUTTING THE PIECES TOGETHER: INTEGRATION TESTS General idea: Constructing software while conducting tests Options: 1. Big Bang 2. Incremental Construction 30 BIG BANG APPROACH All components are combined in advance The entire program is tested as a whole 31 BIG BANG APPROACH All components are combined in advance The entire program is tested as a whole Chaos results! For every failure, the entire program must be taken into account. 32 TOP-DOWN INTEGRATION Top module is tested with stubs (and then used as driver) A Stubs are replaced one at a time StubB Stub Stub (“depth first”) As new modules are integrated, tests are StubC Stub re-run StubD Stub Allows for early demonstration of capability 33 BOTTOM-UP INTEGRATION Bottom modules implemented first and Driver combined into clusters DriverC F Drivers are replaced one at a time Removes the need for complex stubs D E 34 SANDWICH INTEGRATION A Combines bottom-up and top-down integration StubB Stub Stub Top modules tested with stubs, bottom Driver modules with drivers. Combines the best of the two C F approaches D E 35 ONE DIFFERENCE FROM UNIT TESTING: EMERGENT BEHAVIOR Some behaviors are only clear when components are put together. This has to be tested too, although it can be very hard to plan in advance! (It’s almost always discovered after the fact…) Causes test suites/cases to be refactored. 36 NEXT CONCERN: WHO OWNS RESPONSIBILITY FOR TESTING THE SOFTWARE? Developer Independent Tester understands the system must learn about system May test gently if driven by delivery. Likely won’t be gentle if driven by quality, May miss things because of familiarity. but faces a steep learning curve 37 WEINBERG’S LAW A developer is unsuited to test his or her code. From Gerald Weinberg, “The psychology of computer programming” 38 WEINBERG’S LAW Theory: As humans want to be honest with themselves, developers are A developer is unsuited blindfolded with respect to their own mistakes. to test his or her code. Cynical Theory: People are not entirely honest and can take shortcuts. So, how might you change the conditions to avoid these pitfalls? From Gerald Weinberg, “The psychology of computer programming” 39 MAKE EVERYONE A TESTER! ✓ Experienced Outsiders and Clients Good for finding gaps missed by developers, especially domain specific items ✓ Inexperienced Users Good for illuminating other, perhaps unintended uses/errors ✓ Mother Nature Crashes tend to happen during an important client/customer demo… 40 SYSTEM TESTING 41 SPECIAL KINDS OF SYSTEM TESTING Recovery Testing Forces the software to fail in a variety of ways and verifies that recovery is properly performed Security Testing Verifies that protection mechanisms built into a system will, in fact, protect it from unauthorized access/disclosure/modification/destruction Stress Testing Executes a system in a manner that demands resources in abnormal quantity, frequency, or volume Performance Testing Test the run-time performance of software within the context of an integrated system 42 PERFORMANCE TESTING Measures a system’s capacity to process a specific load over a specific time-span, usually: ▪ number of concurrent users ▪ specific number of concurrent transactions ▪ other options: throughput, server response time, server request round-trip time, … Involves defining and running operational profiles that reflect expected use 43 TYPES OF PERFORMANCE TESTING Load Aims to assess compliance with non-functional requirements Stress Identifies system capacity limits Spike Testing involving rapid swings in loa Endurance Continuous operation at a given load (aka Soak) 44 SECURITY TESTING Confidentiality Information protection from unauthorized access or disclosure Integrity Information protection from unauthorized modification or destruction Availability System protection from unauthorized disruption 45 ACCEPTANCE TESTING 46 ACCEPTANCE TESTING Acceptance testing checks whether contractual requirements are met Typically incremental alpha test at production site, beta test at user’s site Work is over when acceptance testing is done 47 WHICH TECHNIQUES SHOULD BE APPLIED? 48 TECHNIQUES FOR EVALUATING SOFTWARE Testing Program (dynamic Analysis verification) (static or dynamic) Inspections Proofs (static verification) (static verification) HOW DO WE KNOW A PRODUCT IS READY? 50 HOW DO WE KNOW WHEN A PRODUCT IS READY? Let the customer test it :-) We’re out of time… Relative to a theoretically sound and experimentally validated statistical model, we have done sufficient testing to say with 95% confidence that the probability of 1,000 CPU hours of failure-free operation is ≥ 0.995. 51 HOW CAN WE CONTROL THE QUALITY OF SUCCESSIVE RELEASES? 52 REGRESSION TESTS Set up automated tests Using, e.G., Junit Ideally, run regression tests after each change If running the tests takes too long: Prioritize and run a subset Apply regression test selection to determine tests
Load more

Recommended publications
  • Software Development Career Pathway
    Career Exploration Guide Software Development Career Pathway Information Technology Career Cluster For more information about NYC Career and Technical Education, visit: www.cte.nyc Summer 2018 Getting Started What is software? What Types of Software Can You Develop? Computers and other smart devices are made up of Software includes operating systems—like Windows, Web applications are websites that allow users to contact management system, and PeopleSoft, a hardware and software. Hardware includes all of the Apple, and Google Android—and the applications check email, share documents, and shop online, human resources information system. physical parts of a device, like the power supply, that run on them— like word processors and games. among other things. Users access them with a Mobile applications are programs that can be data storage, and microprocessors. Software contains Software applications can be run directly from a connection to the Internet through a web browser accessed directly through mobile devices like smart instructions that are stored and run by the hardware. device or through a connection to the Internet. like Firefox, Chrome, or Safari. Web browsers are phones and tablets. Many mobile applications have Other names for software are programs or applications. the platforms people use to find, retrieve, and web-based counterparts. display information online. Web browsers are applications too. Desktop applications are programs that are stored on and accessed from a computer or laptop, like Enterprise software are off-the-shelf applications What is Software Development? word processors and spreadsheets. that are customized to the needs of businesses. Popular examples include Salesforce, a customer Software development is the design and creation of Quality Testers test the application to make sure software and is usually done by a team of people.
    [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]
  • Customer Success Story
    Customer Success Story Interesting Dilemma, Critical Solution Lufthansa Cargo AG The purpose of Lufthansa Cargo AG’s SDB Lufthansa Cargo AG ordered the serves more than 500 destinations world- project was to provide consistent shipment development of SDB from Lufthansa data as an infrastructure for each phase of its Systems. However, functional and load wide with passenger and cargo aircraft shipping process. Consistent shipment data testing is performed at Lufthansa Cargo as well as trucking services. Lufthansa is is a prerequisite for Lufthansa Cargo AG to AG with a core team of six business one of the leaders in the international air efficiently and effectively plan and fulfill the analysts and technical architects, headed cargo industry, and prides itself on high transport of shipments. Without it, much is at by Project Manager, Michael Herrmann. stake. quality service. Herrmann determined that he had an In instances of irregularities caused by interesting dilemma: a need to develop inconsistent shipment data, they would central, stable, and optimal-performance experience additional costs due to extra services for different applications without handling efforts, additional work to correct affecting the various front ends that THE CHALLENGE accounting information, revenue loss, and were already in place or currently under poor feedback from customers. construction. Lufthansa owns and operates a fleet of 19 MD-11F aircrafts, and charters other freight- With such critical factors in mind, Lufthansa Functional testing needed to be performed Cargo AG determined that a well-tested API on services that were independent of any carrying planes. To continue its leadership was the best solution for its central shipment front ends, along with their related test in high quality air cargo services, Lufthansa database.
    [Show full text]
  • Chapter 1 Introduction to Computers, Programs, and Java
    Chapter 1 Introduction to Computers, Programs, and Java 1.1 Introduction • The central theme of this book is to learn how to solve problems by writing a program . • This book teaches you how to create programs by using the Java programming languages . • Java is the Internet program language • Why Java? The answer is that Java enables user to deploy applications on the Internet for servers , desktop computers , and small hand-held devices . 1.2 What is a Computer? • A computer is an electronic device that stores and processes data. • A computer includes both hardware and software. o Hardware is the physical aspect of the computer that can be seen. o Software is the invisible instructions that control the hardware and make it work. • Computer programming consists of writing instructions for computers to perform. • A computer consists of the following hardware components o CPU (Central Processing Unit) o Memory (Main memory) o Storage Devices (hard disk, floppy disk, CDs) o Input/Output devices (monitor, printer, keyboard, mouse) o Communication devices (Modem, NIC (Network Interface Card)). Bus Storage Communication Input Output Memory CPU Devices Devices Devices Devices e.g., Disk, CD, e.g., Modem, e.g., Keyboard, e.g., Monitor, and Tape and NIC Mouse Printer FIGURE 1.1 A computer consists of a CPU, memory, Hard disk, floppy disk, monitor, printer, and communication devices. CMPS161 Class Notes (Chap 01) Page 1 / 15 Kuo-pao Yang 1.2.1 Central Processing Unit (CPU) • The central processing unit (CPU) is the brain of a computer. • It retrieves instructions from memory and executes them.
    [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]
  • Acceptance Testing Tools - a Different Perspective on Managing Requirements
    Acceptance Testing Tools - A different perspective on managing requirements Wolfgang Emmerich Professor of Distributed Computing University College London http://sse.cs.ucl.ac.uk Learning Objectives • Introduce the V-Model of quality assurance • Stress the importance of testing in terms of software engineering economics • Understand that acceptance tests are requirements specifications • Introduce acceptance and integration testing tools for Test Driven Development • Appreciate that automated acceptance tests are executable requirements specifications 2 V-Model in Distributed System Development Requirements Acceptance Test Software Integration Architecture Test Detailed System Design Test See: B. Boehm Guidelines for Verifying and Validating Software Unit Requirements and Design Code Specifications. Euro IFIP, P. A. Test Samet (editor), North-Holland Publishing Company, IFIP, 1979. 3 1 Traditional Software Development Requirements Acceptance Test Software Integration Architecture Test Detailed System Design Test Unit Code Test 4 Test Driven Development of Distributed Systems Use Cases/ User Stories Acceptance QoS Requirements Test Software Integration & Architecture System Test Detailed Unit Design Test These tests Code should be automated 5 Advantages of Test Driven Development • Early definition of acceptance tests reveals incomplete requirements • Early formalization of requirements into automated acceptance tests unearths ambiguities • Flaws in distributed software architectures (there often are many!) are discovered early • Unit tests become precise specifications • Early resolution improves productivity (see next slide) 6 2 Software Engineering Economics See: B. Boehm: Software Engineering Economics. Prentice Hall. 1981 7 An Example Consider an on-line car dealership User Story: • I first select a locale to determine the language shown at the user interface. I then select the SUV I want to buy.
    [Show full text]
  • Model-Based Fuzzing Using Symbolic Transition Systems
    Model-Based Fuzzing Using Symbolic Transition Systems Wouter Bohlken [email protected] January 31, 2021, 48 pages Academic supervisor: Dr. Ana-Maria Oprescu, [email protected] Daily supervisor: Dr. Machiel van der Bijl, [email protected] Host organisation: Axini, https://www.axini.com Universiteit van Amsterdam Faculteit der Natuurwetenschappen, Wiskunde en Informatica Master Software Engineering http://www.software-engineering-amsterdam.nl Abstract As software is getting more complex, the need for thorough testing increases at the same rate. Model- Based Testing (MBT) is a technique for thorough functional testing. Model-Based Testing uses a formal definition of a program and automatically extracts test cases. While MBT is useful for functional testing, non-functional security testing is not covered in this approach. Software vulnerabilities, when exploited, can lead to serious damage in industry. Finding flaws in software is a complicated, laborious, and ex- pensive task, therefore, automated security testing is of high relevance. Fuzzing is one of the most popular and effective techniques for automatically detecting vulnerabilities in software. Many differ- ent fuzzing approaches have been developed in recent years. Research has shown that there is no single fuzzer that works best on all types of software, and different fuzzers should be used for different purposes. In this research, we conducted a systematic review of state-of-the-art fuzzers and composed a list of candidate fuzzers that can be combined with MBT. We present two approaches on how to combine these two techniques: offline and online. An offline approach fully utilizes an existing fuzzer and automatically extracts relevant information from a model, which is then used for fuzzing.
    [Show full text]
  • An Analysis of Current Guidance in the Certification of Airborne Software
    An Analysis of Current Guidance in the Certification of Airborne Software by Ryan Erwin Berk B.S., Mathematics I Massachusetts Institute of Technology, 2002 B.S., Management Science I Massachusetts Institute of Technology, 2002 Submitted to the System Design and Management Program In Partial Fulfillment of the Requirements for the Degree of Master of Science in Engineering and Management at the ARCHIVES MASSACHUSETrS INS E. MASSACHUSETTS INSTITUTE OF TECHNOLOGY OF TECHNOLOGY June 2009 SEP 2 3 2009 © 2009 Ryan Erwin Berk LIBRARIES All Rights Reserved The author hereby grants to MIT permission to reproduce and to distribute publicly paper and electronic copies of this thesis document in whole or in part in any medium now known or hereafter created. Signature of Author Ryan Erwin Berk / System Design & Management Program May 8, 2009 Certified by _ Nancy Leveson Thesis Supervisor Professor of Aeronautics and Astronautics pm-m A 11A Professor of Engineering Systems Accepted by _ Patrick Hale Director System Design and Management Program This page is intentionally left blank. An Analysis of Current Guidance in the Certification of Airborne Software by Ryan Erwin Berk Submitted to the System Design and Management Program on May 8, 2009 in Partial Fulfillment of the Requirements for the Degree of Master of Science in Engineering and Management ABSTRACT The use of software in commercial aviation has expanded over the last two decades, moving from commercial passenger transport down into single-engine piston aircraft. The most comprehensive and recent official guidance on software certification guidelines was approved in 1992 as DO-178B, before the widespread use of object-oriented design and complex aircraft systems integration in general aviation (GA).
    [Show full text]
  • Parasoft Dottest REDUCE the RISK of .NET DEVELOPMENT
    Parasoft dotTEST REDUCE THE RISK OF .NET DEVELOPMENT TRY IT https://software.parasoft.com/dottest Complement your existing Visual Studio tools with deep static INCREASE analysis and advanced PROGRAMMING EFFICIENCY: coverage. An automated, non-invasive solution that the related code, and distributed to his or her scans the application codebase to iden- IDE with direct links to the problematic code • Identify runtime bugs without tify issues before they become produc- and a description of how to fix it. executing your software tion problems, Parasoft dotTEST inte- grates into the Parasoft portfolio, helping When you send the results of dotTEST’s stat- • Automate unit and component you achieve compliance in safety-critical ic analysis, coverage, and test traceability testing for instant verification and industries. into Parasoft’s reporting and analytics plat- regression testing form (DTP), they integrate with results from Parasoft dotTEST automates a broad Parasoft Jtest and Parasoft C/C++test, allow- • Automate code analysis for range of software quality practices, in- ing you to test your entire codebase and mit- compliance cluding static code analysis, unit testing, igate risks. code review, and coverage analysis, en- abling organizations to reduce risks and boost efficiency. Tests can be run directly from Visual Stu- dio or as part of an automated process. To promote rapid remediation, each problem detected is prioritized based on configur- able severity assignments, automatical- ly assigned to the developer who wrote It snaps right into Visual Studio as though it were part of the product and it greatly reduces errors by enforcing all your favorite rules. We have stuck to the MS Guidelines and we had to do almost no work at all to have dotTEST automate our code analysis and generate the grunt work part of the unit tests so that we could focus our attention on real test-driven development.
    [Show full text]
  • Introduction to High Performance Computing
    Introduction to High Performance Computing Shaohao Chen Research Computing Services (RCS) Boston University Outline • What is HPC? Why computer cluster? • Basic structure of a computer cluster • Computer performance and the top 500 list • HPC for scientific research and parallel computing • National-wide HPC resources: XSEDE • BU SCC and RCS tutorials What is HPC? • High Performance Computing (HPC) refers to the practice of aggregating computing power in order to solve large problems in science, engineering, or business. • Purpose of HPC: accelerates computer programs, and thus accelerates work process. • Computer cluster: A set of connected computers that work together. They can be viewed as a single system. • Similar terminologies: supercomputing, parallel computing. • Parallel computing: many computations are carried out simultaneously, typically computed on a computer cluster. • Related terminologies: grid computing, cloud computing. Computing power of a single CPU chip • Moore‘s law is the observation that the computing power of CPU doubles approximately every two years. • Nowadays the multi-core technique is the key to keep up with Moore's law. Why computer cluster? • Drawbacks of increasing CPU clock frequency: --- Electric power consumption is proportional to the cubic of CPU clock frequency (ν3). --- Generates more heat. • A drawback of increasing the number of cores within one CPU chip: --- Difficult for heat dissipation. • Computer cluster: connect many computers with high- speed networks. • Currently computer cluster is the best solution to scale up computer power. • Consequently software/programs need to be designed in the manner of parallel computing. Basic structure of a computer cluster • Cluster – a collection of many computers/nodes. • Rack – a closet to hold a bunch of nodes.
    [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]