Software Engineering I (02161)
|
|
- Reynold Waters
- 6 years ago
- Views:
Transcription
1 Software Engineering I (02161) Week 3 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2016
2 Recap Requirements Engineering functional / non-functional requirements Elicitation, Documentation, Validation Glossary Use Cases use case diagrams detailed use cases descriptions User Stories
3 Use Case Diagram TravelAgency Plan Trip Manage Flights Book Trip «extends» Manage Hotels Administrator User Cancel Trip «extends» Manage Trip Notation is important Actor: Stick figure Relationship actor, use case: solid line, no arrow head Relationship use case, user case: broken line with arrow and <<extends>> or <<includes>> Relationship actor, actor: Generalization: solid line with closed arrow head System boundary: Box
4 Contents Software Testing Acceptance tests JUnit Test Driven Development How calendars and dates work in Java Mock objects
5 Purpose of tests Goal: finding bugs Edsger Dijkstra Tests can show the presence of bugs, but not their absence. Types of bugs: requirement-, design-, implementation errors Types of testing: validation testing Does the software conform to the requirements? Have we built the right system? defect testing Does the software has any unexpected behaviour (e.g. crashes)? Have we built the system right?
6 Validation testing vs defect testing Validation Test (Quality Assurance (QA)) Start city is Copenhagen, destination city is Paris. The date is Check that the list of availabe flight contains SAS 1234 and AF 4245 Defect Test (QA and stress tests) Start city is Copenhagen, the name of the destination city contains the Crtl-L character. Check that the software reacts reasonable and does not crash
7 Types of tests 1. Developer tests (validation testing) a) Unit tests (single classes and methods) b) Component tests (single components = cooperating classes) c) System tests / Integration tests (cooperating components) 2. Release tests (validation and defect testing, QA) a) Scenario based testing b) Performance testing 3. User tests (validation tests) a) Acceptance tests
8 Contents Software Testing Acceptance tests JUnit Test Driven Development How calendars and dates work in Java Mock objects
9 Acceptance Tests Tests defined by / with the help of the user based on the requirements Traditionally manual tests by the customer after the software is delivered based on use cases / user stories Agile software development automatic tests: JUnit, Fit,... created before the user story is implemented
10 Example of acceptance tests Use case name: Login Admin actor: Admin precondition: Admin is not logged in main scenario 1. Admin enters password 2. System responds true alternative scenarios: 1a. Admin enters wrong password 1b. The system reports that the password is wrong and the use case starts from the beginning postcondition: Admin is logged in
11 Manual 1 Success tests scenario Successful Prerequisit: 1 Success the login password scenario for the administrator is adminadmin Input Step Expected Output Fail OK Prerequisit: the password for the administrator is adminadmin Input Step Startup system Expected 0) Exit Output Fail OK 1 Startup system Enter choice 0) Exit 1) Login as administrator 1) Login password administrator adminadmin 1 Enter choice string password logged in adminadmin Enter string logged in 2 Fail scenario Failed Fail login scenario Prerequisit: the password for the administrator is adminadmin Prerequisit: the password for the administrator is adminadmin Input Input Step Step Expected Expected Output Output Fail Fail OK OK Startupsystem system 0) 0) Exit Exit 1) 1) Login Login as administrator as administrator 1 Enter choice password admin Enter string Password incorrect incorrect 0) 0) Exit Exit 1) 1) Login Login as administrator as administrator Automatic test for the main scenario
12 Manual vs. automated tests Manual tests should be avoided They are expensive (time and personal) to execute: Can t be run often Automated tests Are cheap (time and personal) to execute: Can be run as soon something is changed in the system immediate feedback if a code change introduced a bug Regression tests More difficult (but not impossible) when they include the UI Solution: Test under the UI Robert Martin (Uncle Bob) in manual tests are immoral from 36:35 how to test applications having a UI from 40:00
13 Testing under the UI User Thin Presentation Layer Application Layer e.g. LibraryApp Domain Layer e.g. User, Book,... Persistency Layer
14 Automatic tests Successful public void testloginadmin() { LibraryApp libapp = new LibraryApp(); } assertfalse(libapp.adminloggedin()); boolean login = libapp.adminlogin("adminadmin"); asserttrue(login); asserttrue(libapp.adminloggedin()); Failed public void testwrongpassword() { LibraryApp libapp = new LibraryApp(); assertfalse(libapp.adminloggedin()); boolean login = libapp.adminlogin("admin"); } assertfalse(login); assertfalse(libapp.adminloggedin());
15 Contents Software Testing Acceptance tests JUnit Test Driven Development How calendars and dates work in Java Mock objects
16 JUnit Framework for automated tests in Java Developed by Kent Beck and Erich Gamma Unit-, component-, and acceptance tests xunit
17 JUnit and Eclipse JUnit 4.x libraries New source directory for tests
18 JUnit 4.x structure import org.junit.test; import static org.junit.assert.*; public class C public void m1() public void m2() throws Exception {..}... } Independent tests No try-catch blocks (exception: checking for exceptions)
19 JUnit 4.x structure (Before and After)... public class C public void n2() public void n1() public void m1() public void m2() {..}... }
20 Struture of test cases Test class = one use case Test method = one scenario Use inheritance to share sample data between use cases public class SampleDataSetup public void setup() {.. public void teardown {.. }... } public class TestBorrowBook extends SampleDataSetup {..}
21 JUnit assertions General assertion import static org.junit.assert.*; asserttrue(bexp) asserttrue(msg,bexp) Specialised assertions for readability 1. assertfalse(bexp) 2. fail() 3. assertequals(exp,act) 4. assertnull(obj) 5. assertnotnull(obj)...
22 JUnit: testing for exceptions Test that method m() throws an exception public void testmthrowsexception() {... try { m(); fail(); // If we reach here, then the test fails because // no exception was thrown } catch(myexception e) { // Do something to test that e has the correct values } } public void testmthrowsexception() {..}
23 Contents Software Testing Acceptance tests JUnit Test Driven Development Test Driven Development Example of Test-Driven Development Refactoring How calendars and dates work in Java Mock objects
24 Test-Driven Development Test before the implementation Tests = expectations on software All kind of tests: unit-, component-, system tests
25 Test-Driven Development Traditional testing Developer User Quality Assurance (QA) define user requirements UserRequirments understand requirements define system requirements understand requirements SystemRequirments create tests implement Tests System run the tests fix bugs [bugs found] [no bugs]
26 Test-Driven Development Moving to TDD Developer User Quality Assurance (QA) Traditional define user requirements Developer User Quality Assurance (QA) UserRequirments define user requirements understand requirements UserRequirments define system requirements understand requirements SystemRequirments define system requirements understand requirements create tests SystemRequirments create tests Tests implement Tests implement System run the tests System Find defects fix bugs [bugs found] [no bugs] fix bugs create tests [defect found] [no defect]
27 Test-Driven Development Real TDD Traditional Developer User define Quality Assurance (QA) user requirements Developer User Quality Assurance (QA) UserRequirments UserRequirments define user requirements select the feature / user story with highest priority understand requirements define system requirements understand requirements Feature / User Story create test Test SystemRequirments create tests implement and [more features] refactor implement Tests System Find defects System run the tests fix bugs fix bugs [bugs found] create test [defect found] [no bugs] [no defect] [no more features]
28 TDD cycle Repeat for functionality, bug,... red: Create a failing test green: Make the test pass refactor: clean up your code Until: no more ideas for tests Important: One test at a time Implement only as much code so that the test does not fail. If the method looks incomplete, add more failing tests that force you to implement more code
29 Ideas for tests 1. Use case scenarios (missing functions): Acceptance tests 2. Possibility for defects (missing code): Defect tests 3. You want to write more code than is necessary to pass the test 4. Complex behaviour of classes: Unit tests 5. Code experiments: How does the system behave, if... Make a list of new test ideas
30 TDD example: Borrow Book Use case name: borrow book description: the user borrows a book actor: user main scenario: 1. the user borrows a book alternative scenario 1. the user wants to borrow a book, but has already 10 books borrowed 2. the system presents an error message
31 Create a test for the main scenario test data: a user with CPR and book with signature Som001 Test case Retrieve the user with CPR number Retrieve the book by the signature Som001 The user borrows the book The book is in the list of books borrowed by that user
32 Create a test for the main public void testborrowbook() throws Exception { String cprnumber = " "; User user = libapp.userbycprnumber(cprnumber); assertequals(cprnumber,user.getcprnumber()); String signature = "Som001"; Book book = libapp.bookbysignature(signature); assertequals(signature,book.getsignature()); List<Book> borrowedbooks = user.getborrowedbooks(); assertfalse(borrowedbooks.contains(book)); user.borrowbook(book); } borrowedbooks = user.getborrowedbooks(); assertequals(1,borrowedbooks.size()); asserttrue(borrowedbooks.contains(book));
33 Implement the main scenario public void borrowbook(book book) { borrowedbooks.add(book); }
34 Create a test for the alternative scenario test data: a user with CPR , book with signature Som001, and 10 books with signatures book1,..., book10 Test case Retrieve the user with CPR number Retrieve and borrow the books with signature book1,..., book10 Retrieve and borrow the book by the signature Som001 Check that a TooManyBooksException is thrown
35 Implementation of the alternative scenario public void borrowbook(book book) throws TooManyBooksException if (borrowedbooks.size() >= 10) { throw new TooManyBooksException(); } borrowedbooks.add(book); }
36 More test cases What happens if book == null in borrowbook? Test Case: Retrieve the user with CPR number Call the borrowbook operation with the null value Check that the number of borrowed books has not changed
37 Final implementation so far public void borrowbook(book book) throws TooManyBooksException if (book == null) return; if (borrowedbooks.size() >= 10) { throw new TooManyBooksException(); } borrowedbooks.add(book); }
38 Another example Creating a program to generate the n-th Fibonacci number Codemanship s Test-driven Development in Java by Jason Gorman Note: The video uses JUnitMax to run JUnit tests automatically whenever the test files change (junitmax.com) A tool with similar functionality but free is Infinitest (
39 Refactoring and TDD Third step in TDD restructure the system without changing its functionality Goal: improve the design of the system, e.g. remove code duplication (DRY principle) Necessary step Requires good test suite later in the course more about refactoring mechanics
40 TDD: Advantages Test benefits Good code coverage: Only write production code to make a failing test pass Design benefits Helps design the system: defines usage of the system before the system is implemented Testable system
41 Contents Software Testing Acceptance tests JUnit Test Driven Development How calendars and dates work in Java Mock objects
42 How to use Date and calendar (I) Date class deprecated Calendar and GregorianCalendar classes An instance of Calendar is created by new GregorianCalendar() // current date and time new GregorianCalendar(2011, Calendar.JANUARY,10) Note that the month is 0 based (and not 1 based). Thus 1 = February. Best is to use the constants offered by Calendar, i.e. Calendar.JANUARY
43 How to use Date and calendar (I) One can assign a new calendar with the date of another by newcal.settime(oldcal.gettime()) One can add years, months, days to a Calendar by using add: e.g. cal.add(calendar.day_of_year,28) Note that the system roles over to the new year if the date is, e.g One can compare two dates represented as calendars using before and after, e.g. currentdate.after(duedate)
44 Contents Software Testing Acceptance tests JUnit Test Driven Development How calendars and dates work in Java Mock objects
45 Problems How to test that a book is overdue? Borrow the book today Jump to the data in the future when the book is overdue Check that the book is overdue LibraryApp.. getdate... { return new GregorianCalendar() } How do we jump into the future? Replace the GregorianCalendar class by a mock object that returns fixed dates Problem: Can t replace GregorianCalendar class
46 Creating a DateServer class { return dateserver.getdate() } LibraryApp.. getdate... dateserver getdate DateServer { return new GregorianCalendar(); }
47 Creating a DateServer class The DateServer can be mocked { return dateserver.getdate() } LibraryApp.. getdate... dateserver mock(dateserver.class) getdate return a fixed date
48 How to use Import helper methods import static org.mockito.mockito.*; Create a mock object on a certain class SomeClass mockobj = mock(someclass.class) return a predefined value for m1(args) when(mockobj.m1(args)).thenreturn(someobj); verify that message m2(args) has been sent verify(mockobj).m2(args);
49 Mock Example 1: Overdue public void testoverduebook() throws Exception { DateServer dateserver = mock(dateserver.class); libapp.setdateserver(dateserver); Calendar cal = new GregorianCalendar(2011,Calendar.JANUARY,10); when(dateserver.getdate()).thenreturn(cal);... user.borrowbook(book); newcal = new GregorianCalendar(); newcal.settime(cal.gettime()); newcal.add(calendar.day_of_year, MAX_DAYS_FOR_LOAN + 1); when(dateserver.getdate()).thenreturn(newcal); asserttrue(book.isoverdue()); }
50 LibraryApp Code { return dateserver.getdate() } LibraryApp.. getdate... dateserver getdate DateServer { return new GregorianCalendar(); } public class LibraryApp { private DateServer ds = new DateServer(); public setdateserver(dateserver ds) { this.ds = ds;}... } public class DateServer { public Calendar getdate() { return new GreogorianCalendar(); } }
51 Testing for s { return dateserver.getdate() } LibraryApp.. getdate send reminder... dateserver mock(dateserver.class) getdate Returns a fixed date {.. mailservice.send(...).. } mailservice mock(mailservice.class) send Remembers that an was public void test reminder() throws Exception { DateServer dateserver = mock(dateserver.class); libapp.setdateserver(dateserver); } MailService mailservice = mock(mailservice.class); libapp.setmailservice(mailservice);... libapp.send reminder(); verify(mailservice).send("..","..","..");
52 Verify Check that no messages have been sent verify(ms,never()).send(anystring(), anystring(), anystring()); Mockito documentation: googlecode.com/hg/org/mockito/mockito.html
53 Exercises and Next Week Exercises Programming exercise number 3 Exercise 3: Acceptance Tests and TDD Systematic tests and code coverage
Software Engineering I (02161)
Software Engineering I (02161) Week 3 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2013 Recap Requirements Engineering user- / system requirements functional- / non-functional
Software Engineering I (02161)
Software Engineering I (02161) Week 4 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Recap week 1: Introduction week 2: Requirements: Domain model, Use Cases week
Software Engineering I (02161)
Software Engineering I (02161) Week 3 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Contents Programming Tips and Tricks Booleans Constants Delegation Requirements
02291: System Integration
02291: System Integration Week 3 Hubert Baumeister huba@dtu.dk DTU Compute Technical University of Denmark Spring 2018 Contents User Stories Activity Diagrams Acceptance Tests User stories Basic requirements
Software Engineering I (02161)
Software Engineering I (02161) Week 1 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2013 Contents Course Introduction Introduction to Software Engineering Practical
Software Engineering I (02161)
Software Engineering I (02161) Week 1 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2016 Contents Course Introduction Introduction to Software Engineering Practical
Software Engineering I (02161)
Software Engineering I (02161) Week 1 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Contents Course Introduction Introduction to Software Engineering Practical
Software Engineering I (02161)
Software Engineering I (02161) Week 4 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2016 Recap Test in general validation and defect test unit-, component-, system-,
Software Engineering I (02161)
Software Engineering I (02161) Week 9: Layered Architecture Persistency Layer; Software Development Process Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Recap
Software Engineering I (02161)
Software Engineering I (02161) Week 6: Design 1: CRC cards, class and sequence diagram Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Contents Midterm evaluation
Levels of Testing Testing Methods Test Driven Development JUnit. Testing. ENGI 5895: Software Design. Andrew Vardy
Testing ENGI 5895: Software Design Andrew Vardy Faculty of Engineering & Applied Science Memorial University of Newfoundland March 6, 2017 Outline 1 Levels of Testing 2 Testing Methods 3 Test Driven Development
Levels of Testing Testing Methods Test Driven Development JUnit. Testing. ENGI 5895: Software Design. Andrew Vardy
Testing ENGI 5895: Software Design Andrew Vardy Faculty of Engineering & Applied Science Memorial University of Newfoundland March 6, 2017 Outline 1 Levels of Testing 2 Testing Methods 3 Test Driven Development
Software Engineering I (02161)
Software Engineering I (02161) Week 2 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Contents What are software requirements? Requirements Engineering Process Domain
Software Engineering I (02161)
Software Engineering I (02161) Week 5 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2015 Contents From Requirements to Design: CRC Cards Class Diagrams I Sequence Diagrams
Lecture 15 Software Testing
Lecture 15 Software Testing Includes slides from the companion website for Sommerville, Software Engineering, 10/e. Pearson Higher Education, 2016. All rights reserved. Used with permission. Topics covered
Software Engineering I (02161)
Software Engineering I (02161) Week 7 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2018 Contents Sequence Diagrams Object-orientation: Centralized vs Decentralized
Analysis of the Test Driven Development by Example
Computer Science and Applications 1 (2013) 5-13 Aleksandar Bulajic and Radoslav Stojic The Faculty of Information Technology, Metropolitan University, Belgrade, 11000, Serbia Received: June 18, 2013 /
Software Engineering
Software Engineering Lecture 13: Testing and Debugging Testing Peter Thiemann University of Freiburg, Germany SS 2014 Recap Recap Testing detect the presence of bugs by observing failures Recap Testing
Software Engineering I (02161)
Software Engineering I (02161) Week 8 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2016 Last Week State machines Layered Architecture: GUI Layered Architecture: Persistency
Junit Overview. By Ana I. Duncan
Junit Overview By Ana I. Duncan 1 What Is Junit Why Junit, Why test? Junit Lifecycle Junit Examples from CM Other Testing frameworks Resources Before After Agenda 2 JUnit is a member of the xunit testing
Unit Testing and JUnit
Unit Testing and JUnit Moinul Hossain CS 791Z 03/02/2015 Outline What is Software Testing? What and Why Unit Testing? JUnit JUnit features and Examples Test Driven Development (TDD) What is Software Testing?
Software Engineering I (02161)
Software Engineering I (02161) Week 8 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Recap I Last week I Sequence diagrams I Centralized vs. Decentralized Control
Software Engineering I (02161)
Software Engineering I (02161) Week 7 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2016 Contents State machines Library Application and GUI Layered Architecture: Persistence
Test Driven Development TDD
Test Driven Development TDD Testing Testing can never demonstrate the absence of errors in software, only their presence Edsger W. Dijkstra (but it is very good at the latter). Testing If it's worth building,
Software Engineering Testing and Debugging Testing
Software Engineering Testing and Debugging Testing Prof. Dr. Peter Thiemann Universitt Freiburg 08.06.2011 Recap Testing detect the presence of bugs by observing failures Debugging find the bug causing
Software Engineering I (02161)
Software Engineering I (02161) Week 10 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2018 Recap Observer Pattern MVC Presentation Layer Example S.O.L.I.D. Simple Responsibility
COMP 354 TDD and Refactoring
COMP 354 TDD and Refactoring Greg Butler Office: EV 3.219 Computer Science and Software Engineering Concordia University, Montreal, Canada Email: gregb@cs.concordia.ca Winter 2015 Course Web Site: http://users.encs.concordia.ca/
Practical Objects: Test Driven Software Development using JUnit
1999 McBreen.Consulting Practical Objects Test Driven Software Development using JUnit Pete McBreen, McBreen.Consulting petemcbreen@acm.org Test Driven Software Development??? The Unified Process is Use
Software Testing Prof. Meenakshi D Souza Department of Computer Science and Engineering International Institute of Information Technology, Bangalore
Software Testing Prof. Meenakshi D Souza Department of Computer Science and Engineering International Institute of Information Technology, Bangalore Lecture 04 Software Test Automation: JUnit as an example
Agile Manifesto & XP. Topics. Rapid software development. Agile methods. Chapter ) What is Agile trying to do?
Topics 1) What is trying to do? Manifesto & XP Chapter 3.1-3.3 2) How to choose plan-driven vs? 3) What practices go into (XP) development? 4) How to write tests while writing new code? CMPT 276 Dr. B.
Software Engineering I (02161)
Software Engineering I (02161) Week 11 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Recap I Software Development Processes (cont.) I Project Planning I Design
Program Correctness and Efficiency. Chapter 2
Program Correctness and Efficiency Chapter 2 Chapter Objectives To understand the differences between the three categories of program errors To understand the effect of an uncaught exception and why you
Tuesday, November 15. Testing
Tuesday, November 15 1 Testing Testing Waterfall model show testing as an activity or box In practice, testing is performed constantly There has never been a project where there was too much testing. Products
xtreme Programming (summary of Kent Beck s XP book) Stefan Resmerita, WS2015
xtreme Programming (summary of Kent Beck s XP book) 1 Contents The software development problem The XP solution The JUnit testing framework 2 The Software Development Problem 3 Risk Examples delivery schedule
Checking Current Code Coverage
Junit Tests Checking Current Code Coverage We use onap Sonar to track code coverage (sonar.onap.org) To see the appc coverage, click on the appc project on the front page (make sure you choose the most
Software Engineering I (02161)
Software Engineering I (02161) Week 10 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2017 Last Week Layered Architecture: Persistent Layer Software Development Processes
Software Engineering I (02161)
Software Engineering I (02161) Week 9 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2015 Last Week Software Development Process Version Control Contents Project planning
No Source Code. EEC 521: Software Engineering. Specification-Based Testing. Advantages
No Source Code : Software Testing Black-Box Testing Test-Driven Development No access to source code So test cases don t worry about structure Emphasis is only on ensuring that the contract is met Specification-Based
Software Engineering I (02161)
Software Engineering I (02161) Week 5 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2018 Contents User Stories Class Diagrams I Version control User stories Requirements
Testing Stragegies. Black Box Testing. Test case
References: Teach Yourself Object-Oriented Programming in 21 Days by A.Sintes, 1 Testing Stragegies Test case a set of inputs and expected outputs looks at specific piece of functionality to determine
EECS 4313 Software Engineering Testing
EECS 4313 Software Engineering Testing Topic 03: Test automation / JUnit - Building automatically repeatable test suites Zhen Ming (Jack) Jiang Acknowledgement Some slides are from Prof. Alex Orso Relevant
Chapter 8 Software Testing. Chapter 8 Software testing
Chapter 8 Software Testing 1 Topics covered Introduction to testing Stages for testing software system are: Development testing Release testing User testing Test-driven development as interleave approach.
02291: System Integration
02291: System Integration Week 7 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2013 Contents Sequence Diagrams Design Validation: Use Case Realization Example: Interaction
Software Testing Lecture 1. Justin Pearson
Software Testing Lecture 1 Justin Pearson 2017 1 / 50 Four Questions Does my software work? 2 / 50 Four Questions Does my software work? Does my software meet its specification? 3 / 50 Four Questions Does
Black Box Testing. EEC 521: Software Engineering. Specification-Based Testing. No Source Code. Software Testing
Black Box Testing EEC 521: Software Engineering Software Testing Black-Box Testing Test-Driven Development Also known as specification-based testing Tester has access only to running code and the specification
Unit Testing with JUnit and CppUnit
Unit Testing with JUnit and CppUnit Software Testing Fundamentals (1) What is software testing? The process of operating a system or component under specified conditions, observing or recording the results,
Testing with JUnit 1
Testing with JUnit 1 What are we doing here? Learning the mechanics of how to write tests in Java using JUnit Without considering issues like coverage Using JUnit is sometimes called unit testing Unit
Software Engineering I (02161)
Software Engineering I (02161) Week 6 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2016 Contents Sequence Diagrams II Object-orientation: Centralized vs Decentralized
Software Engineering. Top-Down Design. Bottom-Up Design. Software Process. Top-Down vs. Bottom-Up 15/06/2011
CS/ENGRD 2110 Object-Oriented Programming and Data Structures Spring 2011 Thorsten Joachims Lecture 7: Software Design Software Engineering The art by which we start with a problem statement and gradually
02161: Software Engineering I
02161: Software Engineering I Week 9: Version Control, Software Development Process, and Project Introduction Hubert Baumeister Informatics and Mathematical Modelling Technical University of Denmark Spring
Agile Software Development. Lecture 7: Software Testing
Agile Software Development Lecture 7: Software Testing Mahmoud El-Gayyar elgayyar@ci.suez.edu.eg Slides are a modified version of the slides by Prof. Kenneth M. Anderson Outline Testing Terminology Types
Object Oriented Software Design - I
Object Oriented Software Design - I Unit Testing Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa November 28, 2011 G. Lipari (Scuola Superiore Sant Anna) Unit Testing November
Test-Driven Development JUnit
Test-Driven Development JUnit Click to edit Master EECS text 2311 styles - Software Development Project Second level Third level Fourth level Fifth level Wednesday, January 18, 2017 1 Simulator submission
Chapter 3. Unit Testing with JUnit and Debugging. Testing with JUnit getting started. Note
Chapter 3. Unit Testing with JUnit and Debugging By now, you are past the basics and should be familiar with developing Java applications using the Eclipse IDE. Although you must be feeling very confident
C07: Testing and JUnit
CISC 3120 C07: Testing and JUnit Hui Chen Department of Computer & Information Science CUNY Brooklyn College 9/19/2017 CUNY Brooklyn College 1 Outline Recap and issues Grades and feedback Assignments &
Software-Architecture Unit Testing (JUnit)
Software-Architecture Unit Testing (JUnit) Prof. Dr. Axel Böttcher 10. Oktober 2011 Objectives Understand the concept of unit testing Know how to write unit tests Know when to write unit tests Why Unit-Testing?
Manuel Oriol, CHCRC-C, Software Testing ABB
Manuel Oriol, CHCRC-C, 08.11.2017 Software Testing Slide 1 About me 1998 2004 2005 2008 2011 Slide 2 Introduction Why do we test? Did you have to deal with testing in the past? Slide 3 Ariane 5 http://www.youtube.com/watch?v=kyurqduyepi
Software quality. Customers want quality products Bosses want to make money Engineers want to create wonder. Be mindful of your technical debt...
QUALITY ASSURANCE Software quality Customers want quality products Bosses want to make money Engineers want to create wonder Be mindful of your technical debt... 2 Software testing Ultimately, the goal
Tools for Unit Test - JUnit
Tools for Unit Test - JUnit Conrad Hughes School of Informatics Slides thanks to Stuart Anderson 15 January 2010 Software Testing: Lecture 2 1 JUnit JUnit is a framework for writing tests Written by Erich
Test automation / JUnit. Building automatically repeatable test suites
Test automation / JUnit Building automatically repeatable test suites Test automation n Test automation is software that automates any aspect of testing n Generating test inputs and expected results n
Test automation Test automation / JUnit
Test automation Test automation / JUnit Building automatically repeatable test suites Test automation is software that automates any aspect of testing Generating test inputs and expected results Running
02291: System Integration
02291: System Integration Week 7 Hubert Baumeister hub@imm.dtu.dk DTU Compute Technical University of Denmark Spring 2016 Contents Components (part III) Sequence Diagrams Design Validation: Use Case Realization
Automated testing in Agile SW development
T-76.5613 Software Testing and Quality Assurance Automated testing in Agile SW development Seppo Sahi SoberIT seppo.sahi@soberit.hut.fi 2.10.2006 Introduction Agile methods have strong emphasis on practices
Software LEIC/LETI. Lecture 5
Software Engineering @ LEIC/LETI Lecture 5 Last Lecture Verification and Validation Reviews and Inspections Software Testing Coverage Statement, branch, and path coverage Equivalence partitioning Boundary
EECS 4313 Software Engineering Testing. Topic 01: Limits and objectives of software testing Zhen Ming (Jack) Jiang
EECS 4313 Software Engineering Testing Topic 01: Limits and objectives of software testing Zhen Ming (Jack) Jiang Acknowledge Some of the contents are from Prof. Alex Orso, Bil Tzerpos and Gunnar Gotshalks
Program Verification! Goals of this Lecture! Words from the Wise! Testing!
Words from the Wise Testing On two occasions I have been asked [by members of Parliament], Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out? I am not able rightly
https://www.lri.fr/ linaye/gl.html
Software Engineering https://www.lri.fr/ linaye/gl.html lina.ye@centralesupelec.fr Sequence 3, 2017-2018 1/61 Software Engineering Plan 1 2 3 4 5 2/61 Software Engineering Software Testing 3/61 Software
Testing! The material for this lecture is drawn, in part, from! The Practice of Programming (Kernighan & Pike) Chapter 6!
Testing The material for this lecture is drawn, in part, from The Practice of Programming (Kernighan & Pike) Chapter 6 1 Goals of this Lecture Help you learn about: Internal testing External testing General
How technical excellence helps in LeSS adoption. Anton Bevzuk Dodo Pizza Chief Agile Officer
How technical excellence helps in LeSS adoption Anton Bevzuk Dodo Pizza Chief Agile Officer The plan Why engineering practices? Deep dive into Pair Programming Test Automation Continuous Integration Q&A
Software Engineering I (02161)
Software Engineering I (02161) Week 10 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2016 Last Time Project Planning Non-agile Agile Refactoring Contents Basic Principles
Test-Driven Development JUnit
Test-Driven Development JUnit Click to edit Master EECS text 2311 styles - Software Development Project Second level Third level Fourth level Fifth level Wednesday, January 24, 2018 1 Unit Testing Testing
STQA Mini Project No. 1
STQA Mini Project No. 1 R (2) C (4) V (2) T (2) Total (10) Dated Sign 1.1 Title Mini-Project 1: Create a small application by selecting relevant system environment/ platform and programming languages.
Testing! The material for this lecture is drawn, in part, from! The Practice of Programming (Kernighan & Pike) Chapter 6!
Testing The material for this lecture is drawn, in part, from The Practice of Programming (Kernighan & Pike) Chapter 6 1 Words from the Wise On two occasions I have been asked [by members of Parliament],
Programmieren II. Unit Testing & Test-Driven Development. Alexander Fraser.
Programmieren II Unit Testing & Test-Driven Development Alexander Fraser fraser@cl.uni-heidelberg.de (Based on material from Lars Vogel and T. Bögel) July 2, 2014 1 / 62 Outline 1 Recap 2 Testing - Introduction
Automated Unit Testing A Practitioner's and Teacher's Perspective
Automated Unit Testing A Practitioner's and Teacher's Perspective Prof. Peter Sommerlad HSR - Hochschule für Technik Rapperswil Institute for Software Oberseestraße 10, CH-8640 Rapperswil peter.sommerlad@hsr.ch
Software Engineering I (02161)
Software Engineering I (02161) Week 8 Assoc. Prof. Hubert Baumeister DTU Compute Technical University of Denmark Spring 2018 Contents Basic Principles of Good Design Design Patterns Low Coupling High coupling
Tools for Unit Test JUnit
Tools for Unit Test JUnit Stuart Anderson JUnit is a framework for writing tests JUnit 1 Written by Erich Gamma (Design Patterns) and Kent Beck (extreme Programming) JUnit uses Java s reflection capabilities
Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1
Verification and Validation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification vs validation Verification: "Are we building the product right?. The software should
JUnit in EDA Introduction. 2 JUnit 4.3
Lunds tekniska högskola Datavetenskap, Nov 25, 2010 Görel Hedin EDA260 Programvaruutveckling i grupp projekt Labb 3 (Test First): Bakgrundsmaterial JUnit in EDA260 1 Introduction The JUnit framework is
4. A Testing Framework. Oscar Nierstrasz
4. A Testing Framework Oscar Nierstrasz A Testing Framework Sources > JUnit documentation (from www.junit.org) 2 Roadmap > Junit a testing framework > Testing an interface > Testing an algorithm > JExample
Principles of Software Construction: Objects, Design, and Concurrency (Part 2: Designing (Sub )Systems)
Principles of Software Construction: Objects, Design, and Concurrency (Part 2: Designing (Sub )Systems) More Analysis for Functional Correctness Jonathan Aldrich Charlie Garrod School of Computer Science
Agenda. JUnit JaCoCo Project. CSE 4321, Jeff Lei, UTA
Agenda JUnit JaCoCo Project 1 JUnit Introduction A JUnit Example Major APIs Practical Tips 2 Unit Testing Test individual units of source code in isolation Procedures, functions, methods, and classes Engineers
Software Testing. Lecturer: Sebastian Coope Ashton Building, Room G.18
Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 Software Testing 1 Defect Testing Defect testing involves
Software Development Process Models
Software Development Process Models From classical notions to more agile approaches th@cs.toronto.edu, BA8134 Code & Fix or Cowboy Coding 1) Write program 2) Test and fix program Problems: program users
In this lab we will practice creating, throwing and handling exceptions.
Lab 5 Exceptions Exceptions indicate that a program has encountered an unforeseen problem. While some problems place programmers at fault (for example, using an index that is outside the boundaries of
Introduc)on to tes)ng with JUnit. Workshop 3
Introduc)on to tes)ng with JUnit Workshop 3 We have to deal with errors Early errors are usually syntax errors. The compiler will spot these. Later errors are usually logic errors. The compiler cannot
Software Engineering. Unit Testing Gobo Eiffel Test and Clover
Chair of Software Engineering Software Engineering Prof. Dr. Bertrand Meyer March 2007 June 2007 Unit Testing Gobo Eiffel Test and Clover Agenda for Today 1. Testing 2. Main Concepts 3. Unit Testing Gobo
JUnit Testing Patterns: Mocking and Doubles
JUnit Testing Patterns: Mocking and Doubles Produced by: Eamonn de Leastar (edeleastar@wit.ie) Dr. Siobhán Drohan (sdrohan@wit.ie) Department of Computing and Mathematics http://www.wit.ie/ Unit Test Patterns:
Software Design and Analysis CSCI 2040
Software Design and Analysis CSCI 2040 Introduce two important development practices in the context of the case studies: Test-Driven Development Refactoring 2 Logic is the art of going wrong with confidence
CSC Advanced Object Oriented Programming, Spring Specification
CSC 520 - Advanced Object Oriented Programming, Spring 2018 Specification Specification A specification is an unambiguous description of the way the components of the software system should be used and
Software Design Models, Tools & Processes. Lecture 6: Transition Phase Cecilia Mascolo
Software Design Models, Tools & Processes Lecture 6: Transition Phase Cecilia Mascolo UML Component diagram Component documentation Your own classes should be documented the same way library classes are.
JUnit on Eclipse. Chien-Tsun Chen Sep. 23, 2003
JUnit on Eclipse Chien-Tsun Chen Sep. 23, 2003 ctchen@ctchen.idv.tw Outline Introduction to JUnit Using JUnit on Eclipse, By Example Resources Q&A Introduction to JUnit What is JUnit? JUnit is an open
Chapter 15. Software Testing The assert Statement
177 Chapter 15 Software Testing We know that a clean compile does not imply that a program will work correctly. We can detect errors in our code as we interact with the executing program. The process of
TEST-DRIVEN DEVELOPMENT
tdd 2003/6/10 21:42 page 5 #25 Chapter 1 TEST-DRIVEN DEVELOPMENT To vouch this, is no proof, Without more wider and more overt test -Othello,Act 1 Scene 3 William Shakespeare From programmers to users,
Software Engineering I (02161)
Software Engineering I (02161) Week 7 Assoc. Prof. Hubert Baumeister Informatics and Mathematical Modelling Technical University of Denmark Spring 2011 c 2011 H. Baumeister (IMM) Software Engineering I
Introduction to Automated Acceptance Testing
Introduction to Automated Acceptance Testing Micah Martin, 8th Light, Inc. micah@8thlight.com What are Acceptance Tests? What are Acceptance Tests? ATs vs UTs Acceptance Tests Unit Tests Written by Customer
TEST DRIVEN DEVELOPMENT
PERSONAL SOFTWARE ENGINEERING PROJECT: TEST DRIVEN DEVELOPMENT Kirsi Männistö kirsi.mannisto@welho.com 60114V PSEA_Test_driven_development.rtf Page 1 of 1 RoadRunners Change history Version Description
Testing. My favourite testing quote: Program testing can be used to show the presence of bugs, but never to show their absence!
Testing Some resources The most time-consuming of a development project. See for example https://www.itu.dk/people/sestoft/ papers/softwaretesting.pdf - Peter Sestoft testing notes Testing My favourite
JUnit Testing Framework Architecture
JUnit Testing Framework Architecture Unit under test (usually a class or a small number of classes) Test environment (fixture) Program state (e.g., some collection of variables/objects that will be used
Software LEIC/LETI. Lecture 3
Software Engineering @ LEIC/LETI Lecture 3 Last Lecture System Build Continuous Integration Today Test Automation Verification and Validation Human Error, Fault, Error, Failure Verification vs Validation