Alessandro Marchetto Fondazione Bruno Kessler - IRST

1. Design and Write Acceptance Testingfor JabRef Alessandro Marchetto Fondazione Bruno Kessler - IRST

2. Outline • (refresh) Acceptance Testing • (refresh) Change Requirements for JabRef • Design and write acceptance testing for JabRef by using Fitnesse

3. Iterative Software development Write and execute unit tests Execute acceptance tests Write acceptance tests increment + system Prioritized functionalities “Written before” “Executed after the development”

4. Acceptance Testing • Acceptance tests are specified to test that the overall system is functioning as required • Do developers build the right system? • Acceptance tests are based on system scenario/story that contain expectations about the use of the system • When, for a given requirement, all acceptance tests pass, it is considered complete

5. Acceptance testing: a black-box approach 1.describe the system using a use-cases diagram * identify the functionality that must be implemented by the system 2.detail each use-case with a textual description enriched with pre/post conditions and flow of events * events are related to: (i) the interactions between system and user; and (ii) the expected actions of the system * a flow of events is composed of basic and alternate flows 3.define instances of each use-case executing the system for realizing the functionality * identify usage scenarios per each functionality 4.define set of test cases for each scenario 5.(opt) define additional test cases to test the interaction between use-cases.

6. Additional information and examples • Jim Heumann. Generating Test Cases From Use Cases. Online IBM journal. 2001 • http://ww.ibm.com/developerworks/rational/library/content/RationalEdge/jun01/GeneratingTestCasesFromUseCasesJune01.pdf • Peter Zielczynski. Traceability from Use Cases to Test Cases. online IBM journal 2006 • http://www.ibm.com/developerworks/rational/library/04/r-3217/

7. How to select input values? Different approaches can be used: • Random values • Tester Experience • Domain knowledge • Equivalence classes • Boundary values • Combinatorial testing • ….

8. Output Table The Fitnesse picture o ≠ o’ Developer Test Runner Fixture o’ i Customer/ Analyst (i, o) System User Story Fit Table O = expected output O’ = actual output

9. Iterative Software development (considering Fitnesse and change requirements) Write and execute unit tests Execute acceptance tests Write acceptance tests increment + system Prioritized functionalities “Written before” “Executed after the development”

10. Iterative Software development (considering Fitnesse and change requirements) • Tasks: • Understand the change requirements • Understand the initial system code that must • be evolved • Identify acceptance tests • Implement acceptance tests by means of • Fitnesse Write acceptance tests …today laboratory for JabRef

11. An example: Football team Website • The initial system • a Website that manages football teams • The change requirement: • A sports magazine decides to add a new feature to its Website that will allow users to view top football teams based on their ratings.

12. user scenario (change requirement) acceptance tests

13. Test1: Table “verify the rating is calculated properly” A) We use a column fixture B) We fill the table with test cases

14. Test1: Fixture “verify the rating is calculated properly” A) We partially implement the supporting fixture public class VerifyRating extends ColumnFixture { public String teamName; public int played; public int won; public int drawn; public int lost; public long rating() { return 0; } } …to be “fixed” after the implementation of the change requirement

15. Project Plan: activities • Initialization • Project introduction • Code understanding • Acceptance test design • Implementation • Code implementation • Unit testing implementation • Acceptance test implementation • Fitnesse and GUI • Coverage Analysis • Test suite/s improvement • Regression Analysis • Project report

16. Change requirements for the course project • Consolidating bibtex files • Shrinking bibtex files • Exporting to HTML tables must include all the links • Ordering items and save to .bib files

17. Laboratory: acceptance tests for change requirements in JabRef • Tasks: • Understand the change requirements • identify functionalities, subtasks to realize • each functionality, and usage scenarios • Understand the initial system code that must • be evolved • identify the evolved/usable package and • classes • Identify acceptance tests • convert scenarios in test cases • Implement acceptance tests by means of • Fitnesse • write fit-tables • write (non-fully implemented) fixtures Write acceptance tests

18. Example • Consolidating bibtex files • Input • A folder of bib files • Output • - A unique bib files with all (non duplicated) entries found in the input bib files • Sub-Tasks: • 1- Load bibtex entries taken from different files in a given directory into a unique list • 2- Detect conflicts among entries (same authors, title, publication, etc.) • 3- Resolve conflicts • remove duplication from the db • 4- Get the new entry list • 5- Write the list into a bibtex file • !! If possible use the already implemented JabRef functionality

19. Project Deliverables • Eclipse project • FITNESSE test cases • GUI test cases • JUnit test cases • Source code (including changes) • Added test cases for coverage and mutation testing • Project report • Description of FITNESSE test cases • Description of GUI test cases • Description of JUnit test cases • Description of the change implementation • Coverage and mutation report • Regression report (prioritization) Submit to: studio.empirico@gmail.com Email subject: [SWAT-2011 Project] – Student’s Name