Design Acceptance Tests for the JabRef project

advertisement
Design and Write
Acceptance Testing
for JabRef
Alessandro Marchetto
Fondazione Bruno Kessler - IRST
Outline



(refresh) Acceptance Testing
(refresh) Change Requirements for JabRef
Design and write acceptance testing
for JabRef by using Fitnesse
Iterative Software development
Write
acceptance
tests
Write
and
execute
unit tests
Execute
acceptance
tests
increment
+ system
“Written before”
Prioritized
functionalities
“Executed after the development”
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
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.
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/jun0
1/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/
How to select input values?
Different approaches can be used:
-
-
Random values
Tester Experience
Domain knowledge
Equivalence classes
Boundary values
Combinatorial testing
….
Output Table
The Fitnesse picture
o ≠ o’
Developer
Fixture
Test Runner
o’
i
Customer/
Analyst
(i, o)
System
User Story
Fit Table
O = expected output
O’ = actual output
Iterative Software development
(considering Fitnesse and change requirements)
Write
acceptance
tests
Write
and
execute
unit tests
Execute
acceptance
tests
increment
+ system
“Written before”
Prioritized
functionalities
“Executed after the development”
Iterative Software development
(considering Fitnesse and change requirements)
Write
acceptance
tests
Tasks:
1) Understand the change requirements
2) Understand the initial system code that must
be evolved
3) Identify acceptance tests
4) Implement acceptance tests by means of
Fitnesse
…today laboratory for JabRef
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.
user scenario
(change requirement)
acceptance tests
Test1: Table
“verify the rating is calculated properly”
A) We use a column fixture
B) We fill the table with test cases
Test1: Fixture
“verify the rating is calculated properly”
A) We partially implement the supporting fixture
public class VerifyRating extends ColumnFixture {
public
public
public
public
public
String teamName;
int played;
int won;
int drawn;
int lost;
public long rating() {
return 0;
}
}
…to be “fixed” after the implementation
of the change requirement
Project Plan: activities
(1) Initialization
• Project introduction
• Code understanding
(2) Acceptance test design
(3) Implementation
• Code implementation
• Unit testing implementation
(4) Acceptance test implementation
• Fitnesse and GUI
(5) Coverage Analysis
• Test suite/s improvement
(6) Regression Analysis
(7) Project report
Change requirements for the course project
(1) Consolidating bibtex files
(2) Shrinking bibtex files
(3) Exporting to HTML tables must include all the links
(4) Ordering items and save to .bib files
Laboratory: acceptance tests for change
requirements in JabRef
Write
acceptance
tests
Tasks:
1) Understand the change requirements
• identify functionalities, subtasks to realize
each functionality, and usage scenarios
2) Understand the initial system code that must
be evolved
• identify the evolved/usable package and
classes
3) Identify acceptance tests
• convert scenarios in test cases
4) Implement acceptance tests by means of
Fitnesse
• write fit-tables
• write (non-fully implemented) fixtures
Example
A)
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
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
Download