In this assignment, you will write another complete class that is intended to reinforce your skills in writing instance variables, accessors, and mutator methods, while also increasing the use of if statements to provide conditional logic. You will also write tests to verify the proper operation of your code.

Your task is to develop software that monitors and controls the operation of the power sliding door of a minivan.

Requirements

The state of the door system is governed entirely by the following operational rules:

The door can be locked or unlocked at any time, by using a lock/unlock button on the dashboard. When the door is closed, the door can only be successfully opened if: 1) the gear shift lever is in park; and 2) the door is unlocked. In such a state, any of the following mechanisms will successfully open the door: 1) an open button on the dashboard; 2) a handle on the outside of the door; or 3) a handle on the inside of the door. However, the inside handle mechanism will not open the door if a separate child-safety mechanism has been engaged, regardless of any other conditions. The child-safety mechanism can only be engaged or disengaged while the door is open. The door can be closed at any time. The gear can be changed at any time.

You will write a class that represents these features and manages the sliding door. In addition to maintaining the current state of the sliding door system, your class will also generate an event log containing a history of all attempts to change the state of the system (whether successful or not). To test your system, rather than writing an informal tester class as in the previous assignment, you will develop a comprehensive test suite using the JUnit framework, which will need to test the entirety of your implementation.

System Description

You will develop a class called _MinivanDoor in the _{edu.vt.cs5044} package that models the behavior and state of the sliding door of the minivan. The methods of this class will be invoked by other systems, displays, and sensors within the minivan to indicate certain requests or activities. The methods of your implementation must behave according to the operational rules above. Your class will provide the following public methods, plus any private instance variables and private methods as needed:

Constructor:

MinivanDoor() initializes the minivan door system to its default state:

door is closed door is unlocked child-safety is disengaged gear shift lever is in park event log is empty Accessors:

isOpen() request the state of the door isLocked() request the state of the doors lock isChildSafe() request the state of the child-safety feature getGear() request the state of the gear shift lever getLastLogEntry() request the most recent entry from the event log (returns _null if the event log is

empty)

getLogEntryCount() request the number of entries in the event log

getLogEntryAt(int index) request the specified log entry event (returns _null if the index is invalid) Mutators*:

setGear(Gear gear) indicate an activation of the gear shift lever setChildSafe(boolean engage) indicate an activation of the child-safety (on or off) pushLockButton() indicate an activation of the dashboard lock button pushUnlockButton() indicate an activation of the dashboard unlock button pushOpenButton() indicate an activation of the dashboard open button pullInsideHandle() indicate an activation of the inside handle pullOutsideHandle() indicate an activation of the outside handle closeDoor() indicate an activation of the door closure sensor

(*Each mutator call must always result in exactly one _LogEntry value appended to the event log, even if no state is actually mutated due to the operational rules. The event log must be stored as an ArrayList<LogEntry> field.)

You will also develop a comprehensive JUnit test class called _{MinivanDoorTest} to confirm proper operation of your _MinivanDoor implementation.

Downloads

MinivanDoor.java source file with method placeholders

MinivanDoorTest.java JUnit test file with sample test methods

Gear.java enumeration type for gear shift values

LogEntry.java enumeration type for log entry values

Getting Started With Eclipse

Create a new Java Project for this assignment, and within the src folder of that project create a new Package named _{edu.vt.cs5044} for your code. Within this package you need to copy all of the provided files, except the _{MinivanDoorTest} file.

The _MinivanDoor class already has an empty constructor, one private instance variable, and placeholders for the public methods listed above. There is only enough code to satisfy the compiler at this point, so the methods certainly dont yet work as intended. However, we have at least something that compiles, in order to demonstrate how JUnit works (see below).

Youll also need to add Eclipse support for JUnit for this project, so right-click your project, select Build Path | Add Libraries, then highlight JUnit and click Next. Select the version as JUnit 4 (Note: this is NOT the default version) and click Finish to add the built-in JUnit library.

Next, it will be very useful later in this project to have a separate source folder structure for you test file. To create this, right-click your project and select New | Source Folder. (If Source Folder is not an option, select Other instead and type source to search for it.) Name the new source folder test and click Finish.

In the project at this point, you should see both the test and the src folders, along with nodes for the JRE System Library and JUnit 4.

Finally, right-click test folder, add a new Package named _{edu.vt.cs5044} there, and copy the provided MinivanDoorTest file into this package.

Working With JUnit

Background

For the first time, youll develop a formal test suite via JUnit, so you can much more readily self-check your code as you write it. Youve probably already seen how self-checking with a tester class can allow you to find your own errors as early as possible during the development process. Now well use JUnit to help automate this process completely, making it even easier to develop and run test code.

JUnit is optimized for software test cases to be developed as individual methods. Each test method has the @Test annotation, a nice (often long) descriptive name beginning with test by convention, and a simple structure with three main steps: 1) Setup the initial conditions; 2) perform the one action to be tested, which is typically a single mutator call; and 3) confirm the resultant behavior via assertions. Provided Test File

Open the _{MinivanDoorTest} file provided above, and refer to it for the next few sections.

It may look a bit odd at first, but this file contains three (working and complete) sample test methods. One validates the constructor, one tests locking the door, and one tests attempting to open the locked door via the button. Notice that each test method requires the _@Test annotation immediately above its signature. That tells JUnit to treat this as a test method. Theres also another method with the the _@Before annotation. JUnit will call that method each time (and before) any of the _@Test methods is executed. So here, every test method will automatically have access to a default (newly-constructed) _MinivanDoor object. Note also that JUnit test classes should not declare constructors, nor should they contain a main method.

Initial Conditions

In some cases, such as two of the provided examples, the _@Before method is entirely sufficient, so no additional setup code is needed within the _@Test methods. However, many _@Test methods (as in the third provided sample) will need to manipulate that default object to prepare other initial conditions required for the test. Often this setup is achieved by calling other test methods, but any setup code is acceptable.

Action To Be Tested

Performing the one action you want to test is typically pretty easy, since its usually just a single mutator method call. Just make sure its very clear in every test method exactly what action is being tested. Also, its important to resist the temptation to test multiple actions within a single test method. You should always create a new test any time you want to test an additional action. The first test method can act as the setup for the second action, if applicable. Youll naturally end up using lots of copy-and-paste when developing test cases, and thats perfectly acceptable. Assertions (Con rming Results)

To confirm the action actually did what it was supposed to do, JUnit provides a family of _{assert__()} methods that let you state the expected results in code. Keep in mind that an assertion is just a claim about something that you expect. If an assertion is valid during execution, the code simply continues normally.

Reaching the end of the test method without any failed assertions means your code passed that test. However, as soon as any assertion fails, that test method immediately stops executing, reporting exactly which assertion failed.

There are actually dozens of _{assert__()} methods available in the JUnit library, but the ones you will probably find most useful for this assignment are assertEquals(), assertTrue(), assertFalse(), and assertNull(). There are examples of each in the provided file. In assertions such as _{assertEquals()}, where two values are required, the expected value goes first, while the actual value goes second.

Lets Do This!

Finally, to actually run your tests, right-click on your _{MinivanDoorTest} class in the package explorer view and choose Run As | JUnit Test to execute all the tests. Eclipse will show the results in a JUnit pane, as a tree of tests (with tiny or x badges) along with a green or red bar. A red bar means that at least one test method had an assertion that failed. At this point we expect all our tests to fail, since we havent implemented anything yet, so a red bar it is. But now we have a goal, to make that bar green!

Double-click one of the test methods that failed, and the editor will jump to and highlight the exact assertion that failed. The Failure Trace at the bottom of the JUnit pane will also show more details about the expected values. For example, double-click the constructor defaults test in the tree. Youll see the _getGear() assertion line highlighted in your test file, and this line in the failure trace below:

This is as expected, since we only have placeholder code for _getGear() at this point. Note that the placeholder code did actually happen to pass a few of the assertions, but that was purely coincidental!

Planning Your Development

Read through the description for each method, thinking about how you might implement and test the behavior, then plan an order in which you want to implement the methods. Its completely natural to adjust your plan as you go along, but at least just choose one to get started for now. The constructor and most of the basic accessors should be relatively easy to test and implement first.

Once youve selected a method to implement, dont implement it quite yet! First, try to write at least one test method before you start coding the implementation. The new tests will almost certainly fail when you first run them, but your code will begin to pass as you start to develop the method. This strategy goes by the names of Test-First Coding and Test-Driven Development (which are slightly different from each other, but not in a way that matters to us). Sometimes youll find you need to start coding a new method to get your current method to pass every test, but try to continue this process by writing at least one test case for that new method before starting its implementation.

Additional Hints and Tips

ArrayList

As noted above, the event log is to be held as an ArrayList<LogEntry> which is a collection well cover in detail very soon. For now, just create a private field like this:

Then, in the constructor, you must initialize this field to a new empty _ArrayList that will hold the LogEntry objects:

To populate the list, we use the add() method, for example:

There are many ways to query the list, but well only require the following two:

In the get() method above, note that _i is an index location within the list, where the first entry is at index location zero.

Enumeration Types

You have been provided source code for two pre-defined enumeration types (specifically _LogEntry and

Gear ) to be used within several of the required methods. Please use this code exactly as provided, without modification. See Horstmann 5.4 for a little more background on the usage of enumeration types. The basic idea is that weve defined a set of distinct constant values, in a way that leverages Javas natural type-safety system. This ensures that our code can only ever use valid values, as enforced by the compiler, thus eliminating typos and many other common mistakes. Code Path Test Coverage

Your test file will need to achieve 100% coverage of you _MinivanDoor implementation for full credit in WebCAT. As you test your code, you may find that Web-CAT indicates you have certain conditions that are not being completely tested by your own tests. Youll need to include tests for each unique way an overall condition can be true or false. This may require you to test the same action youve already tested, but starting from a different set of initial conditions, to exercise every possible branch.

Note that you do NOT need to achieve 100% coverage on the enumerated type files (Gear and LogEntry). Even if you exercise every value, youll still notice a single missed line of coverage, due to the way enum classes are handled internally. However, if youd like to cover those last lines, you can add the following test method to your test file as a workaround:

This test method serves only to complete the coverage the enum files.

Test Coverage of Short-Circuits

Due to short-circuit of logical operations, if you have N boolean expressions joined by AND or OR, you will only need N+1 test cases for full coverage. For example, testing a conditional with 2 components such as (isThis && !isThat) requires 3 distinct test cases:

Overall false:

when _isThis is false, regardless of the _!isThat value

when _isThis is true, and _!isThat is false Overall true:

when _isThis is true, and _!isThat is true.

Web-CAT will highlight any such conditions you havent fully tested, but it cant tell you exactly which of these possibilities you have left untested. Impossible Test Coverage

Redundancies in your conditionals can make it impossible to cover all branches with test cases, even if the code works exactly as intended. A very simple example is the following:

}

All branches of the second conditional above cannot be tested, because _!isReady at that point can never be false. To resolve this, you must remove any redundant components from the conditionals.