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, bu ...

1. 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.

2. 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

3. 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 ()

4. 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 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 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 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.

5. 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 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 ()

6. 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 )

7. Transfer funds between two accounts of a single customer.
List 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

8. You need to test any non-trivial methods your group decides are
a good idea.
class Transaction implements Comparable
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:

9. 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,

10. 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:

11. public class MyTestSuite {
private List 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 );

12. 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.