Congratulations!! You have 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.
You have 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.)
Requirements:
In this project, you will be given a list of classes and their public methods, for a simple (not realistic) banking simulation program. 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.
Download BankSimSkeleton.zip.
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.
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 the “Account.getBalance()” method. In general, such methods are trivial to implement and do not need unit tests, 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.)
The Classes to Test:
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 banking simulation. These classes and their more important methods are described below. Note all classes are in the package banking.
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 Customer.addSavingsAccount. Similarly, you will need a Bank object to create a Customer.
Class Bank
Class Bank is responsible for the main method, 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 diagram).
Bank ( name )
Creates a new Bank object with the given name
static void main ( String[] args )
Handles initialization tasks (such as persistence, if that was implemented in this project, which it is not)
void addCustomerGUI ()
Add a new customer to the bank, using a GUI
String addCustomer ( String lastName, String firstName )
Add a new customer to the bank; return the customer’s ID
Customer getCustomer ( String customerId )
Get a Customer object, given a customer’s ID
List<Customer> getCustomer ( String lastName, String firstName )
Get a List of Customer objects, given a customer’s last and first names. (In general there may be multiple customers with the same names; for testing, assume customer names are unique.)
SortedSet<Customer> getAllCustomers ()
Generates a report of all current customers, in customer ID order, and returns a SortedSet of customers
void removeCustomer ( String customerId )
Deletes a customer from the bank. (In reality, just marks the customer as non-current.)
SortedSet<Account> getAllAccounts ()
Generates a report of all current accounts by all customers, in account ID order, and return a Sorted Set of accounts
Getters, setters, toString, and other methods as needed
You need to test any non-trivial methods your group decides are a good idea.
Class Customer
Class 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 )
Creates a new Customer object from a name. Note for this project, we assume names are unique.
SavingsAccount addSavingsAccount ( double initBal, String description )
Creates and returns new savings account, with the specified initial balance and account description
Account getAccount ( String accountId )
Returns an Account with the given account ID, or null if no such account
SortedSet<Account> getCustomerAccounts()
Returns a read-only SortedSet of the customer’s active accounts (if any)
void removeAccount ( String accountId )
Removes an Account with the given account ID; in a real program, you don’t delete info, just mark it deleted.
double YtdFees ()
the total fees paid by this customer for year-to-date
double YtdInterest ()
Returns the total interest paid to this customer for year-to-date
Getters, setters, toString, and other methods as needed
You need to test any non-trivial methods your group decides are a good idea.
abstract class Account
Class 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 )
Constructor for abstract class, taking a customer, initial balance, and an account description.
abstract void deposit ( double amount )
Add money into account
abstract void withdraw ( double amount )
remove money from account
static void transfer ( Account fromAccount, Account toAccount, double amount )
Transfer funds between two accounts of a single customer.
List<Transaction> getTransactions ()
Returns a List of all transactions for this account.
Transaction getTransaction ( int transactionId )
Returns the specified transaction.
Getters, setters, toString, and other methods as needed
(For example, getBalance.) You need to test any non-trivial methods your group decides are a good idea.
class SavingsAccount extends Account
Class SavingsAccount is an Account, but includes monthly interest payments. A field defaultInterestRate holds the assigned monthly interest rate, and has both a setter and a getter.
SavingsAccount ( double initialBalance, String customerId, String description )
Create a new savings account with the specified initial balance, for the specified customer, and with the given account description
void addInterest ()
Adds a transaction “INTEREST PAYMENT” based on this account’s monthly interest rate.
Getters, setters, toString, and other methods as needed
You need to test any non-trivial methods your group decides are a good idea.
class Transaction implements Comparable<Transaction>
Class 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)
Create a new transaction
Getters, setters, (for example, to get and possibly set the id, transaction timestamp, type, amount, and description), toString, and other methods as needed
You need to test any non-trivial methods your group decides are a good idea.
enum TransactionType
Enum TransactionType lists all possible transaction types: DEPOSIT, WITHDRAWAL, INTEREST, CHECK, FEE, PENALTY, and ADJUSTMENT.
Potential Changes (Requirements not part of the provided RFP):
To be determined, but there are sure to be lots of them.
Project Procedure:
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!
Once you have created that skeleton (it shouldn’t take long), you 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
A great way to proceed is propose tests for everything, and then you can merge the best ideas of those. (If you don’t do that, design the tests for each public class member.) In addition to producing a list of tests, you should also document which methods you have decided not to test, and state why. (Not necessary for missing getters, setters, toString, etc.)
Hints:
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 “return value;”. You should review the Testing resources provided on the class web page, which include the testing lecture notes, links to JUnit API and other documentation, and examples and demos.
Short JUnit Refresher:
With JUnit, you use the methods of the class org.junit.Assert, such as assertEquals or assertFalse, inside of test methods which are marked with the “@Test” annotation. These test methods, along with other methods and fields, are part of a class known as a test suite.
For example, for the scoreDetail method, your test might look something like this:
public class MyTestSuite {
@Test
public void testScoreDetailLegalInput () {
final int[] correctScores = { … };
final Round r = new Round( …);
int [] scores = r.scoreDetail();
assertNotNull( scores );
assertArrayEquals( correctScores, scores );
}
}
That is just one test case, with a single legal Round object. It is likely your tests will need many Round or other objects, so you should check into creating a test fixture. A test fixture is simply one or more methods that get called prior to each test method’s invocation. Such methods can reset (or initialize) various fields in your test suite, so each test starts with a clean slate. In this case, you could create a method that sets up some objects for you:
public class MyTestSuite {
private List<Course> courseList;
private Round legalRound1;
private int [] legalRound1CorrectScores;
private Round badRound;
…
@Before
public void init () {
courseList = …;
legalRound = ….;
legalRound1CorrectScores = { … };
badRound = ….;
…
}
@Test
public void testScoreDetailLegalInput1 () {
int [] scores = legalRound1.scoreDetail();
assertNotNull( scores );
assertArrayEquals( legalRound1CorrectScores, scores );
}
@Test
public void testScoreDetailBoundryValues1 () {
…
}
…
}
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 both Eclipse and NetBeans 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.
