Congratulations!! Your team has been selected to create a banking simulator. After meeting with the clients, you have agreed on requirements and even have developed a basic design of the program. Basically, the software must be able to create accounts, deposit, withdraw, and transfer funds, and deal with fees, interest, etc.
Your software development group has decided to embrace Test-Driven Development (TTD) for this project. This means that, now that the requirements and design have been developed, the next step is to design unit tests for all the classes identified in the design. (Normally you might develop the tests at the same time as starting the implementation, but for this project, we are only developing unit tests.)
View the UML class diagram for the bank simulation. (You can learn about UML from the class resources.)
In this project, you will be given a list of classes and their public methods, for a simple (not realistic) banking simulation program. These comprise the design, or specification, for a banking simulator. Your group's task is to create a thorough set of unit tests. In order to run your tests, you will skeleton classes with stub methods; you should not attempt to actually create a banking simulation program! To save time, I have provided a zip file with the skeleton classes. You should probably add all those, and a package for your unit tests, before your initial commit.
Since there is no real code to test (only stub methods), it is expected that all your tests will fail. Keep in mind you are only to create unit tests, not a working program. (So, do not implement ANY of the banking simulator's methods.)
Naturally a real banking system needs persistent data (CRUD) to hold account data between runs of the program and many other features. Normally you would need to test that functionality as well. To keep this project simple, no persistence classes or methods need to be tested, and are not mentioned in this project's requirements. No exception handling is included in this project either.
In other words, this simulation is not terribly realistic. (As a matter of fact, it is not a great design either!) For a first project where you must create unit tests in a group, it should be complex enough as is. Keep in mind the requirements for testing on financial software is high, so be sure to have sufficient tests for the simulator (and not just a few “happy path” tests).
Note that of the six classes shown, some may not have any methods except trivial ones, and thus do not require any unit tests. Some of the methods shown might be considered trivial by your team; you shouldn't include tests for those either. Additionally, some methods cannot be tested easily using JUnit, such as methods that display a GUI. Don't try to test such methods, although some of them are shown in the requirements. Testing such functionality requires advanced tools and techniques, such as GUI testers and a mocking framework (e.g., Mockito).
I have also omitted nearly all getters and setters, toString, compareTo,
clone, and other such methods from the requirements, but of course
a real program must have them as needed.
You can actually see those methods in the skeleton classes, for example
In general, such methods are trivial to implement and do not need unit
testing, although it is likely you will need to use getters and possibly
setters in your unit test methods.
However, if your team feels any of those methods merit a unit test,
add appropriate unit tests for them.
(It isn't as if adding additional tests is ever a bad thing, just that
often it's a waste of time.)
For the initial version, we can find many candidate classes but
in the end only a few are needed to meet the requirements for a simple
these classes and their more important methods are described below.
Note all classes are in the package
Take some time to example these classes and their methods.
See how they can be used in your tests.
For example, to create a
SavingsAcccount to test
you need to create a
Customer first, since the only method
to create accounts is
Similarly, you will need a
Bank object to create a
Bank is responsible for the
managing customers, and keeping track of various fees and interest rates;
only the fees and rates have setter methods (only one shown in the class
Bank ( String name )
static void main ( String args )
void addCustomerGUI ()
String addCustomer ( String lastName, String firstName )
Customer getCustomer ( String customerId )
List<Customer> getCustomer ( String lastName, String firstName )
SortedSet<Customer> getAllCustomers ()
void removeCustomer ( String customerId )
SortedSet<Account> getAllAccounts ()
Customer is responsible for managing a customer's details,
including that customer's accounts.
Fields include a reference to the owning bank, a unique customer ID,
Customer's first and last names, and a SortedSet of transactions (not a List
for no particular reason).
Only the customer's name fields have setters.
Customer( String lastName, String firstName )
SavingsAccount addSavingsAccount ( double initBal, String description )
Account getAccount ( String accountId )
void removeAccount ( String accountId )
double YtdFees ()
double YtdInterest ()
abstract class Account
Account is responsible for managing the details of any type
of account, including an accountId, customerId, description, account creation
date, the current balance, and the account's transaction list.
Only the account description has a setter.
Account ( Customer cust, double initBal, String description )
abstract void deposit ( double amount )
abstract void withdraw ( double amount )
static void transfer ( Account fromAccount, Account toAccount, double amount )
List<Transaction> getTransactions ()
Transaction getTransaction ( int transactionId )
getBalance.) You need to test any non-trivial methods your group decides are a good idea.
SavingsAccount extends Account
SavingsAccount is an Account, but includes monthly
A field defaultInterestRate holds the assigned monthly interest rate, and has
both a setter and a getter.
SavingsAccount ( double initialBalance, String customerId, String description )
void addInterest ()
class Transaction implements Comparable<Transaction>
Transaction objects represent any deposit, withdrawal, or
other transaction on an account.
(Note transfers are implemented as a pair of transactions.)
This class contains files for a transaction ID, a timestamp (the
date and time of the transaction), the type of transaction, the amount,
and a description.
None of these fields have setters.
Transaction(TransactionType type, double amount, String description)
TransactionType lists all possible transaction types:
DEPOSIT, WITHDRAWAL, INTEREST, CHECK, FEE, PENALTY, and ADJUSTMENT.
You will need to create skeleton classes with stub methods for all classes and methods in the design. (A Zip with the skeletons is provided for you, as a starting point.) They should compile and run, but do nothing. Do not implement any methods! When complete, upload to a GitHub repo for this project.
Once you have created that skeleton (it shouldn't take long), your team can write and then run the JUnit tests. Naturally, it is expected that all the tests will fail, since the stub methods don't do what they are supposed to do. While developing tests, you may decide additional classes and/or methods are needed. If so, include skeletons/stubs for those as well. Do not forget to include any such design documents (if you change or add to the design) in your projects documentation (in the repo).
Decide who within your group will be responsible for which classes and methods to create tests for. A great way to proceed is to have all group members propose tests for everything, and then your team can merge the best ideas of those. (If you don't do that as a team, have at least two team members designing the tests for each public class member.) In addition to producing a lists of tests, your team should also document which methods you have decided not to test, and state why. (Not necessary for missing getters, setters, toString, etc.)
Having decided on which tests to have, divide up the list so each team member has about the same number of tests they must implement. Document who has been assigned which tests to implement in a file, and keep that in the repo's documentation. As usual, each member should work in their own branch.
When someone has implemented one or more tests, they should push their branch to the project's GitHub repo, so code review can begin. Every team member should read the code and make any suggestions, or ask any questions that occur to them. If changes are needed (for example, additional test cases seem to be needed), the author goes back to fix those, then pushes the updates for a new round of code review. Once a set of tests is approved by the group, merge them into the master branch using your group's agreed upon merging strategy (for example, only the team leader merges into master, or the branch owner must do the merge).
Right after any merge into master event, all group members should do a Pull to refresh their local copy of the master branch.
A rating of each team member's level of participation, from each member should be sent directly to the instructor. Be sure to include yourself in the ratings! The rating is a number from 0 (didn't participate at all), 1 (less than their fair share of the work), 2 (participated fully), or 3 (did more than their fair share of the work). (Additional comments are not required, but may be included if you feel that is necessary. I will keep such comments as confidential as possible under Florida law.)
A link to your group's GitHub repo for this project. (As usual, only the master branch will be examined and graded.) For this project, the latest commit on the master branch, done before the due date, is the version that will be graded. You can send your rating and link to (preferred).
In this project, I will be grading the quality and thoroughness of your unit
tests, and the quality of the accompanying documentation (which methods
you didn't feel it necessary to test, as described above).
I will also be checking if you have tests you shouldn't, such as a getter
method that does only “
You should review the
resources provided on the class web page, which include the testing
lecture notes, links to JUnit API and other
documentation, and examples and demos.
With JUnit, you use the methods of the class
org.junit.Assert, such as
assertFalse, inside of test methods which are marked
with the “
These test methods, along with other methods and fields, are part of
a class known as a test suite.
Methods marked with
@Before all get called before every
@Test method does, every time.
You can also create
@After methods, to cleanup stuff.
(You can also have static methods marked with
@BeforeClass”, which get run once at the start
of a test run.
You could use that to re-create a sample file, setup a database,
or start some server program.)
Remember that all popular IDEs have wizards to create test suites (Eclipse uses the term Test Case for the class). The hard part is to come up with a good set of tests. You want confidence that if all the tests pass, the code being tested correctly implements the design.