Minivan Solution

Minivan Solution

In this assignment, you will write another complete class that is intended to reinforce your basic skills in writing instance variables, getter methods, and setter methods, while also introducing the use of if statements to provide conditional logic, controlled by boolean conditions based on object state. You will also switch from writing "tester programs" that just print output to writing repeatable, automatically executable software tests for your work using the JUnit testing framework.
The subject of this assignment is inspired by one of the programming exercises from Chapter 5 of the textbook, which is based on the textbook author's own minivan. If you drive a late model minivan with power doors, you might recognize some of these behaviors yourself.
Your task is to simulate a portion of the control software for the vehicle. You will write a class that represents the state of the controls, providing accessor and mutator methods for the state of the relevant vehicle switches. You will also provide methods that represent door opening actions, and that implement logic matching the description provided below.
Details
The textbook author's minivan has two power sliding doors. Each door can be opened by either a dashboard switch, its inside handle, or its outside handle. However, the inside handles do not work if the minivan's child lock switch is activated. In order for the sliding doors to open, the gear shift must be in park, and the master unlock switch must be activated. You will write a class that represents these vehicle features, and models the process of deciding whether a sliding door will open or not.
At the same time, you will also write software tests to confirm your solution works the way it should. Instead of writing a "tester" program that just prints out expected results, you will instead write your software tests using the JUnit testing framework, which makes it much easier to repeatedly run and recheck test results as you work.
Unit Testing
In this assignment, you'll begin writing software tests for your work so that you can self-check your code as you write it. Self-checking is an important way for your to confirm your code works the way you expect, and it is really helpful at allowing you to find your own errors as you work.
Sometimes, students with more experience programming aren't too excited about writing software tests, which is understandable. They can seem a bit boring. However, if you remember back to your math classes or writing classes during your earlier education, you probably recall at least some time you spent checking your own work. In math, when you solve an equation, it is a really good idea to plug the answer you came up with back into the original equation to see if it works. That's a really strong way to double-check your work to make sure that simple mechanical mistakes (like accidentally flipping a sign, or other small errors) get found right away. Similarly, when writing you're probably used to repeatedly proof-reading your own words--that is a useful self-checking technique, but it isn't quite as reliable as "plugging the answer back into the original", because there's no definitive way to tell if your proof-reading found all the problems. Still, you do it because it helps improve the quality of your work.
So, software testing the way we're going to practice it in this class amounts to the same thing: it is your way of self-checking your own work to find mistakes. Further, if you self-check each piece of your code as you write it you'll find more errors faster. If you write all your code first, and save all the self-checking for the end, your self-checking won't find as many errors. Worse still, when you find a problem, you may not know exactly where in your assignment the problem is, and it can take a lot longer to locate the cause of the mistake and fix it. Generally speaking, if you test your own code as you write it, you'll find more errors faster, and save more time later compared to saving software testing (i.e., self-checking) until the end after your entire assignment is complete. So please write software tests for each method, as you write that method rather than saving testing for the end.
Requirements
1. Write a class called Minivan that models the door-opening behavior of our minivan. Your class should provide the following methods (you define the instance variables/fields you need):
2. Minivan() This default constructor initializes the van so that the child lock switch is off (deactivated), the master unlock switch is on (activated), and the gear shift is in park.
3. getChildLock() A boolean accessor method that returns the state of the child lock switch as a boolean value (false == off and true == on).
4. setChildLock(boolean value) A setter method that turns the child lock switch on or off.
5. getMasterUnlock() A boolean accessor method that returns the state of the master unlock switch as a boolean value (false == off and true == on).
6. setMasterUnlock(boolean value) A setter method that turns the master unlock switch on or off.
7. getGearShiftPosition() An accessor method that returns the position of the gear shift as a single char value, which is one of: 'P', 'R', 'N', '1', '2,' ,'3', or 'D'.
8. setGearShiftPosition(char value) A setter method that sets the gear shift position. Expected values are one of: 'P', 'R', 'N', '1', '2,' ,'3', or 'D'. You may assume that only one of these values will be passed in (you are not required to verify that only legal values are used in this method for this assignment).
9. pullLeftOuterHandle() A method that represents pulling the outside handle of the left sliding door, assuming the door is already in the closed position. This method returns a boolean value indicating whether the door opens (true) or remains closed (false). We will assume the door is returned to the closed position by the vehicle's operator before the next method is called.
10. pullLeftInnerHandle() A method that represents pulling the inside handle of the left sliding door, assuming the door is already in the closed position. This method returns a boolean value indicating whether the door opens (true) or remains closed (false). We will assume the door is returned to the closed position by the vehicle's operator before the next method is called.
11. pullLeftDashSwitch() A method that represents pulling the dashboard switch for the left sliding door, assuming the door is already in the closed position. This method returns a boolean value indicating whether the door opens (true) or remains closed (false). We will assume the door is returned to the closed position by the vehicle's operator before the next method is called.
12. pullRightOuterHandle() A method that represents pulling the outside handle of the right sliding door, assuming the door is already in the closed position. This method returns a boolean value indicating whether the door opens (true) or remains closed (false). We will assume the door is returned to the closed position by the vehicle's operator before the next method is called.
13. pullRightInnerHandle() A method that represents pulling the inside handle of the right sliding door, assuming the door is already in the closed position. This method returns a boolean value indicating whether the door opens (true) or remains closed (false). We will assume the door is returned to the closed position by the vehicle's operator before the next method is called.
14. pullRightDashSwitch() A method that represents pulling the dashboard switch for the right sliding door, assuming the door is already in the closed position. This method returns a boolean value indicating whether the door opens (true) or remains closed (false). We will assume the door is returned to the closed position by the vehicle's operator before the next method is called.
Design
For this assignment, you'll notice that there are some features that are repeated (perhaps with minor variations) in the Minivan class. If you review the program grading rubric for this course, you will notice that "repeated code" is one of a number of design weaknesses that can cause your solution to receive lower ratings. When you discover these sections of repeated code, consider creating your own "helper" method(s) so that you can write such code once, and simply call it in multiple places instead of repeating it.
Also, as you test your code, you may find that Web-CAT indicates you have logical conditions (if statements) that are not being thoroughly tested. When you have multiple conditions combined with && or ||, make sure you include separate tests for each unique way the condition can succeed or fail. For example, if you have an if statement that includes a condition like (isHappy || !isBusy) remember that there are 3 separate ways the condition can be determined. First, if isHappy is true, the condition will also be true. However, if isHappy is false, there are two more possibilities (either isBusy is true, or isBusy is false). You'll need to test all three possibilities for an if statement with this kind of condition in order to get full credit. In general, if there are K basic conditions or comparisons in an if statement, then there are K + 1 test cases needed to cover all the possibilities (in this example, 2 basic conditions means 3 separate test situations). Web-CAT will highlight conditions you haven't fully tested, but it won't tell you which possibilities you missed--you have to figure that out yourself, based on the tests you have written.
Powered by