Java代写 | CSC 216 SE Materials


CSC 216 SE Materials
Part 1 of this assignment laid out the requirements for the Issue Manager application that you must create. Part 2 details the design that you must implement and

Project 1 Part 2 MUST be completed individually.
Set Up Your Work Environment
Before you think about any code, prepare your work environment to be compatible with the teaching staff grading criteria. The teaching staff relies on NCSU GitHub
and Jenkins for grading your work. Follow these steps:
1. Create an Eclipse project named
Project1: Right click in the package explorer, select New > Java Project. Name the project Project1. (The project naming is case
sensitive. Be sure that the project name begins with a capital P and ends with a 1. There are no spaces in the project name.)
2. If you have not already done so, clone your remote NCSU GitHub repository corresponding to this project. Note that each major project will have its own
The requirements for this project are described in Project 1 Part 1. The Problem Overview describes the Issue Management FSM. The system is further described in
eight different use cases:
UC1: Issue File Interactions
UC2: Issue List
Project 1, Part 1: Issue Manager
You are expected to complete the project individually. All work must be strictly your own.
2020/2/15 CSC 216 SE Materials 2/13
UC3: New State
UC4: Working State
UC5: Confirmed State
UC6: Verifying State
UC7: Closed State
Your program must implement the teaching staff design, which is described below. The design consists of 12 different classes (5 as inner classes), 3 enumerations,
and 1 interface. We are providing the interface (
IssueState – which should be an inner interface of the Issue class) and the graphical user interface front-end
edu.ncsu.csc216.issue_manager.model Classes in the edu.ncsu.csc216.issue_manager.model package form the model portion of the IssueManager system.
edu.ncsu.csc216.issue_manager.model.command. Sub-package of edu.ncsu.csc216.issue_manager.model containing the object representation of a command that a
user would make in the Issue Manager that might initiate a state change. This is an example of the
Command Pattern.
Command. Encapsulates the information about a user command that would lead to a transition. Contains two inner enumerations.
CommandValue. An enumeration contained in the Command class (i.e., an inner-enumeration). Represents one of the five possible commands that a user can
make for the Issue Manager FSM. See the information about Enumerations in the implementation section – the code is provided.
Resolutions. An enumeration contained in the Command class (i.e., an inner-enumeration). Represents the four possible ways a user can resolve an issue. See the
information about Enumerations in the implementation section where the code is provided.
edu.ncsu.csc216.issue_manager.model.issue. Sub-package of edu.ncsu.csc216.issue_manager.model containing the State Pattern implementation of the Issue
Manager FSM.
IssueState. Interface that describes behavior of concrete IssueState classes for the Issue Manager FSM. You cannot change this code in any way. All concrete
*State classes must implement IssueState. IssueState is an inner interface of the Issues class. All of the *State classes that implement IssueState are also inner
classes of
Issue. Concrete class representing the State Pattern context. An Issue keeps track of all issue information including the current state. The state is updated when a
Command encapsulating a transition is given to the Issue. Issue encapsulates the five concrete *State classes and one enumeration.
NewState: Concrete class that represents the new state of the Issue Manager FSM.
WorkingState: Concrete class that represents the working state of the Issue Manager FSM.
ConfirmedState: Concrete class that represents the confirmed state of the Issue Manager FSM.
VerifyingState: Concrete class that represents the verifying state of the Issue Manager FSM.
ClosedState: Concrete class that represents the closed state of the Issue Manager FSM.
IssueType: an enumeration contained in the Issue class. Represents the two possible Issue types of bug and enhancement. Sub-package of edu.ncsu.csc216.issue_manager.model containing file processing classes.
IssueReader. Processes a file containing issue information and creates a List of Issues. If there are any errors while processing, the entire file is considered invalid
and an
IllegalArgumentException is thrown with the message “Unable to load file.” (see UC1, E1).
IssueWriter. Writes the given list of Issues to the file name provided. If there are any errors while processing, an IllegalArgumentException is thrown with the
message “Unable to save file.” (see UC1, E2).
The project you push to NCSU GitHub must contain unmodified versions of the files that we provide for you unless stated otherwise by the
2020/2/15 CSC 216 SE Materials 3/13
edu.ncsu.csc216.issue_manager.model.manager. Sub-package of edu.ncsu.csc216.issue_manager.model containing the list of Issues and the overarching
IssueManager functionality.
IssueList. Concrete class that maintains a current list of Issues in the Issue Manager system.
IssueManager. Concrete class that maintains the IssueList and handles Commands from the GUI. IssueManager implements the Singleton Design Pattern.
Classes in the edu.ncsu.csc216.issue_manager.view package implement the view-controler of the IssueManager program.
edu.ncsu.csc216.issue_manager.view.ui. Sub-package of edu.ncsu.csc216.issue_manager.view containing the view-controller elements of the Issue Manager ModelView-Controller pattern.
IssueManagerGUI. The graphical user interface for the project. This is the class that starts execution of the program. You cannot change this code in any way. The
IssueManagerGUI interacts with the rest of the system through the IssueManager singleton.
UML Diagrams
The UML class diagram for the design is shown in the figure below. The fields and methods represented by green circles (public) or yellow diamonds (protected)
represent the minimum set of visible state and behavior required to implement the project.
Access Modifiers
Note: You can modify the names of private variables, parameters, and methods. However, you MUST have the non-private data and methods
(names, return types, parameter types and order) exactly as shown for the teaching staff tests to run. YOU MAY NOT ADD ANY ADDITIONAL PUBLIC
Figure 1: Issue Manager UML class diagram
UML Diagram Notations
UML uses standard conventions for display of data, methods, and relationships. Many are illustrated in the UML diagram above. Here are some things you should
or a red square in front of a class member means private.
+ or a green circle in front of a class member means public.
# or a yellow triangle in front of a class member means protected.
Static members (data or methods) are underlined.
Methods that are declared but not defined (abstract methods or those declared in interfaces) are in italics, unless they are in an interface.
The names of abstract classes are in italics.
Dotted arrows with triangular heads point to interfaces from the classes that implement them.
Solid arrows with triangular heads go from concrete classes to their parents.
Solid arrows with simple heads indicate has-a relationships (composition). The containing class is at the tail of the arrow and the class that is contained is at the
head. The arrow is decorated with the name and access of the member in the containing class. The arrow is also decorated with the “multiplicity” of the
relationship, where 0..1 means there is 1 instance of the member in the containing class. (See c on the arrow from Command to CommandValue.) A multiplicity of
0..* means there are many, usually indicating a collection such as an array or collection class. (See
issues on the arrow from IssueList to Issue.)
A circle containing an “X” or cross sits on a the border of a class that contains an inner (nested) class, with a line connecting it to the inner class. (See the class
ClosedState and its corresponding outer class Issue. See also the enumerations.)
Our UML diagram has some additional graphic notation:
A red square (empty or solid) in front of a name means private. Solid squares are methods and empty squares are data members. (See
A green circle (empty or solid) in front of a name means public. (See
A yellow diamond (empty or solid) in front of a name means protected.
SF in front of a name means static, final. (See
Methods embellished with C are constructors. (See
Issue.Issue().) Private methods embellished with a C are constructors in private inner classes. (See
IssueManager.IssueManager().) Note that while all classes require a constructor, not all constructors require implementation. In some cases the default
constructor is sufficient.
Implementation Process
Professional software development is more than building working software. The process of building software is important in supporting teams of developers to build
complex systems efficiently. We expect you to follow good software engineering practices and processes as you create your software to help you become a better
software developer and to help with understanding your progress on the project. We have
general software engineering practices we expect you to follow
throughout the project, you will be evaluated on some of these as per the
grading rubric at the end of the project. Additionally, we have Process Points Milestone that
will help you work on the project. The
Process Points 1 Milestone is a compiling skeleton and commented code. The Process Points 2 Milestone is completion of
roughly half the project. Deadlines are listed at the top of this page and on Moodle. There are no late deadlines for process points.
General Software Engineering Practices
Commit with meaningful messages.
Run your CheckStyle and PMD tools locally
and make sure that all your Javadoc is correct. Make sure the tools are configured correctly (see configuration
) and set up the tools to run with each build so you are alerted to style notifications shortly after creating them.
Practice test-driven development. Start by writing your test cases. This will help you think about how a client would use your class (and will help you see how that
class might be used by other parts of your program). Then write the code to pass your tests.
Process Points 1 Milestone
Process Points 1 Milestone gets you started with the project and ensures that you meet the design and that you start commenting your code.
Compile a skeleton. The class diagram provides a full skeleton of what the implemented Issue Manager program should look like. Start by creating an Eclipse
project named
Project1. Copy in provided code and create the skeletons of the classes you will implement, including the test classes. Ensure that the packages,
class names, and method signatures match the class diagram exactly! If a method has a return type, put in a place holder (for example,
return 0; or return null;) so
that your code will compile. Push to GitHub and make sure that your Jenkins job shows a yellow ball. A yellow ball on Jenkins means that 1) your code compiles,
2) that the teaching staff tests compile against your code, which means that you have the correct code skeleton for the design, and 3) you have a skeleton of your
test code in the
test/ folder.
Comment your code. Javadoc your classes and methods. When writing Javadoc for methods, think about the inputs, outputs, preconditions, and post conditions.
Meaningful Commit Messages
The quality of your commit messages for the entire project history will be evaluated for meaning and professionalism as part of the process points.
Process Points 2 Milestone
The Project 1 build process is set up differently than the builds for Guided Project 3 and labs. Instead of requiring that you have unit tested all of your classes with
high quality tests that executed 80% of statements (i.e., 80% statement coverage) before running and reporting the results of the teaching staff tests, the Project 1
build process will provide teaching staff test feedback in a scaffolded, incremental manner. This means that you can focus on one class at a time and as you complete
each class more information will be revealed.
The build process will consider the classes in the design in the following order:
(all methods except update()
All teaching staff test feedback will be removed for any of your classes with PMD test notifications. The teaching staff test results will be removed for any of your
classes that have insufficient coverage from high quality test cases. The class order is there to help you focus on classes that others depend on first. For example,
when you pass your tests and the teaching staff tests for
Command class, you can then have increased confidence that Command will work when you use it to test
the FSM in the
Issue class.
To earn full credit for Process Points 2, you should have 80% statement coverage from high quality unit tests, no PMD JUnit notifications, and be passing all of your
unit tests and the teaching staff unit tests for roughly half of the project. That means you should be passing all unit tests in the following 8 teaching staff test files:
TS_CommandTest, TS_IssueTest, TS_IssueNewStateTest, TS_IssueConfirmStateTest, TS_IssueWorkingStateTest, TS_IssueVerifyingStateTest, and
TS_IssueClosedStateTest. At this point you will have implemented your FSM.
You should be passing the rest of the teaching staff tests by the final deadline which includes the following 4 additional teaching staff test files:
TS_IssueWriterTest, TS_IssueListTest, and TS_IssueManagerTest.
If any of the teaching staff test feedback is not revealed to you, your build’s console output will contain the following string
see the number of teaching staff tests that have NOT run and are displayed a few lines higher up in the console output. While the build should be configured to only
go to green ball when all teaching staff tests are revealed and you have sufficient coverage and no static analysis notifications, the system is in beta.
It is your responsibility to ensure that all ELEVEN teaching staff test files are reporting results and that you’re passing the tests to ensure completion of the project.
You can check to see if the teaching staff tests have run by exploring the Test Results links in on the build and checking that all twelve teaching staff test files are
If you run into any problems with the build that you think are scaffolding related, please email Dr. Heckman directly ([email protected]) or
@ her in a Piazza
post so she will receive the notification about the issue. Dr. Heckman will work to resolve issues within 24 hours of notification, but an issue may not be resolved
after 4pm on the Process Points 2 deadline until the following day. Please plan accordingly and start early!
Compiling Skeleton & Fully Commented Classes
Fully commented classes and methods on at least a skeleton program are due at least two weeks before the final project deadline to earn the
associated process points. See the deadline for Process Points 1 at the top of this document.
We suggest you work on Project 1 Part 2 one piece at a time. The details below provide the suggested implementation order and details about the implementation.
Package edu.ncsu.csc216.issue_manager.model.command.
The Command class creates objects that encapsulate user actions (or transitions) that cause the state of a Issue to update. We recommend that you start with the
Command class because the Issue class and the concrete States rely on a correctly working Command class.
Command should include an enumeration for the possible commands that can cause transitions in our FSM (CommandValue) and for the different resolution types
Resolution). Our textbook defines enumeration as “a type that has only a small number of predefined constant values.” Since there are a discrete number of actions
a user can take and a set number of resolutions, an enumeration is quite appropriate to list those values.
Copy the code below into the
Command class exactly as given. You can include the enumeration code with the fields of Command. Enumerations are pseudo-objects
(like arrays). Constructors are listed in the class diagram, but are not needed in the implementation.
You should Javadoc these enumerations using class-level-like
To access a value in the enumeration, use the enumeration name followed by the value (for example, CommandValue.ASSIGN). Enumerated types are essentially a
name given to an integer value. Therefore, you can use primitive comparison operators (
== and !=) to compare enumerated type variables (of the same enumerated
type – don’t try to compare a
CommandValue with a Resolution!). Enumerated types can also be the type of a variable. For example, Issue’s resolution field is of type
Resolution. See pp. 1133-1134 in the Reges and Stepp textbook for more details on enumerated types.
Command constructor has 4 parameters: CommandValue c, String ownerId, Resolution r, String note. Not all parameters are required for each CommandValue.
Unneeded values can be passed as
null or ignored when the Command is used by the Issue FSM. Any The following conditions result in an
IllegalArgumentException when constructing a Command object:
Command with a null CommandValue parameter. A Command must have a CommandValue.
Command with a CommandValue of ASSIGN and a null or empty string ownerId.
Command with a CommandValue of RESOLVE and a null resolution.
Command with a null note parameter.
The remaining methods are standard getters for the fields.
Package edu.ncsu.csc216.issue_manager.model.issue
The issue package holds the context (Issue), abstract state (the interface IssueState), and the concrete states (all the *State classes) of the State design pattern for the
Issue Manager FSM.
Issue represents an issue managed by our system. A Issue knows its issueId, state, issueType, summary, owner, whether it is confirmed, its resolution, and all of its
notes. Each Issue has its own state, which is updated from Commands propagated to it from the UI.
The five concrete
*State classes implement IssueState. IssueState should be an inner interface of Issue. The *State classes should be inner classes of Issue. Every
IssueState must support two behaviors: 1) update when given a Command and 2) know its name.
Issue has the following constants:
I_ENHANCEMENT: A constant string for the “Enhancement” issue type.
I_BUG: A constant string for the “Bug” issue type.
NEW_NAME: A constant string for the new state’s name with the value “New”.
WORKING_NAME: A constant string for the working state’s name with the value “Working”.
CONFIRMED_NAME: A constant string for the confirmed state’s name with the value “Confirmed”.
public enum CommandValue { ASSIGN, CONFIRM, RESOLVE, VERIFY, REOPEN }
public enum Resolution { FIXED, DUPLICATE, WONTFIX, WORKSFORME }
VERIFYING_NAME: A constant string for the verifying state’s name with the value “Verifying”.
CLOSED_NAME: A constant string for the closed state’s name with the value “Closed”.
Issue has an inner enumeration, IssueType. Use the following code for the IssueType enumeration.
Issue has the following fields needed for an issue:
issueId: Unique issue id for an issue.
state: Current state for the issue of type IssueState.
issueType: Type of issue – either a IssueType.ENHANCEMENT or IssueType.BUG.
summary: Issue’s summary information from when the issue is created.
owner: User id of the issue owner or null if there is not an assigned owner.
confirmed: True if the issue is confirmed. The confirmed field can only be set to true if the issue is a bug.
resolution: Issue resolution of type Resolution or null if there is not an assigned Resolution.
notes: An ArrayList of notes.
counter: A static field that keeps track of the id value that should be given to the next Issue created.
Issue maintains one instance of every concrete IssueState class. These instances may be the current state of the Issue at any given time. All of the IssueState
instances should be final.
newState: Final instance of the NewState inner class.
workingState: Final instance of the WorkingState inner class.
confirmedState: Final instance of the ConfirmedState inner class.
verifyingState: Final instance of the VerifyingState inner class.
closedState: Final instance of the ClosedState inner class.
Issue has two constructors:
Issue(IssueType issueType, String summary, String note): Constructs a Issue from the provided IssueType, summary, and note. If any of the parameters are null or
empty strings, then an
IllegalArgumentException is thrown. The issueId field is set to the value stored in Issue.counter. The counter is then incremented using
Issue.incrementCounter(). The rest of the fields are initialized to the parameter values, null, false, or an empty object type as appropriate. The note is added to a
ArrayList<String> object.
Issue(int id, String state, String issueType, String summary, String owner, boolean confirmed, String resolution, ArrayList<String> notes): The fields of the Issue
are set to the values from the constructor, which should be used from the IssueReader class. You may find it useful to create private helper methods to set the
fields for
Issue. This constructor checks the constraints on Issue objects listed in UC2, S2. Note: there were a few updates to this list due to a couple of conflicting
Additionally, if the incoming issueId is greater than the current value in Issue.counter, then the Issue.counter should be updated to the issueId + 1
using the
setCounter(id) method.
Issue has getters and setters to handle working with the field information. All setters must be private and are optional, but strongly recommended. The private
setters are intended to be used for the full
Issue constructor only. The getters return information that would be appropriate for display in the GUI.
update(Command) method drives the finite state machine by delegating the Command to the current state and if successful adding non-null notes to the notes
list. The update() method throws an UnsupportedOperationException if the current state determines that the current transition is not appropriate for the FSM. The
toString() method returns the string representation of the Issue that is printed during file save operations (e.g., UC2, S3 & S4).
Issue has five inner classes that each implement IssueState. The inner classes each represent the five states in the Issue Manager FSM. Each concrete IssueState
handles updating when given a Command. If the Command is not appropriate for the current state, then the concrete IssueState’s update() method throws an
UnsupportedOperationException. Otherwise, the state is updated as appropriate for the Command. A concrete IssueState also knows its name. The use case
associated with each concrete
IssueState is below:
NewState: UC3
WorkingState: UC4
public enum IssueType { ENHANCEMENT, BUG }
ConfirmedState: UC5
VerifyingState: UC6
ClosedState: UC7
The io package holds the classes that handle file input and output. Since the methods are static, there are no explicit composition relationships modeled in the class
diagram. However,
IssueManager (and the teaching staff tests) will depend on these files working to test IssueList and IssueManager.
IssueReader has one public method readIssuesFromFile that receives a String with the file name to read from. If there are any errors when processing the file (e.g.,
the file cannot be found or an error during processing like too many items in a line or unable to process a
Issue) the readIssuesFromFile method will throw an
IllegalArgumentException with the message “Unable to load file.”
IssueReader class will use the Issue(int id, String state, String issueType, String summary, String owner, boolean confirmed, String resolution, ArrayList<String>
constructor to create a Issue object from the file input. If the Issue constructor throws an IllegalArgumentException because the requirements from UC2, S2
are unmet, you can allow that exception to propagate to the
IssueReader caller; no need to catch and create a new exception.
Issue is represented on multiple lines of the file because of the way that notes are handled. Processing the issue file line by line is possible, but makes it very
difficult to use helper methods. Instead, we suggest that you do the following to help with processing things an
Issue at a time:
Create a String object and read the whole file into the String object, line by line. You’ll need to add in
\n characters at the end of each line since those are used as
delimiters when reading in line by line.
Parse the String containing the whole file using the delimiter
“\\r?\\n[*]”. This delimiter is looking for carriage return and new line characters followed by the *
character to break apart the string. This will create multi-line Strings of text that can be transformed into an Issue. This issue string can be passed to a private
helper method (ours is named
processIssue(String)) to create an Issue object or throw an exception if there’s a problem.
For breaking apart the line of
Issue fields, use [+] as a delimiter.
IssueWriter has one public method writeIssuesToFile that receives a String with the file name to write to and a List of Issues to write. IssueWriter should use Issue’s
toString() method to create the properly formatted output for a Issue. If there are any errors, an IllegalArgumentException is thrown with the message “Unable to
save file.”
Package edu.ncsu.csc216.issue_manager.model.manager
The manager package contains the two classes that manage all Issues during program execution.
A IssueList maintains a List of Issues (you may use either an ArrayList or a LinkedList from the Java Collections Framework as the constructed type). IssueList
supports the following list operations:
add a
Issue to the list
adding a collection of
Issues to the list
remove a
Issue from the list
search for a
Issue in the list by id
update a
Issue in the list through execution of a Command
return the entire list or sublists of itself (for example, the IssueList can return a List of Issues filtered by IssueType)
When creating a new
IssueList, reset the Issue’s counter to 0. When creating an IssueList from the contents of an issue file (e.g., via the addIssues() method), set the
Issue’s counter to the maxId in the list of XML issues plus 1 (this uses the min/max looping paradigm). Use Issue.setCounter(int) to set the counter.
The addIssue(IssueType issueType, String summary, String note) has the same parameters as the Issue(IssueType issueType, String summary, String note)
constructor. Error checking on the parameters can be delegated to the Issue constructor.
When working with methods that receive an
issueId parameter, there is no need to error check or throw an exception if the issueId does not exist in the list. For
getIssueById, return null. For all other methods, do not change the internal state of the list.
Separation of IssueList from IssueManager means each class can have a very specific abstraction: IssueList maintains the List of Issues and IssueManager controls
the creation and modification of (potentially many)
IssueManager implements the Singleton design pattern. This means that only one instance of the IssueManager can ever be created. The Singleton pattern ensures
that all parts of the
IssueManagerGUI are interacting with the same IssueManager at all times. Note that the IssueManagerGUI does not have a global reference (or a
field) to
IssueManager. Since IssueManager is a Singleton, the GUI can access that single instance at any time with a call of IssueManager.getInstance() since
getInstance() is a static method.
IssueManager works with the files that contain the saved Issues. Therefore, IssueManager works closely with the IssueReader and IssueWriter classes. If IssueReader
or IssueWriter throw an IllegalArgumentException, it should be allowed to propagate up to the IssueManager caller.
IssueManager also provides information to the GUI through methods like getIssueListAsArray(), getIssueListAsArrayByIssueType(String issueType), and
getIssueById(). The first two of these methods return a 2D Object array that is used to populate the IssueTableModel (inner class of the
IssueManagerGUI.IssueListPanel) with information. The 2D Object array stores [rows][columns]. The array should have 1 row for every Issue that you need to return.
There should be 4 columns:
Index 0.
Issue’s id number
Index 1.
Issue’s state name
Index 2.
Issue’s issue type
Index 3.
Issue’s summary
If the
issueType String passed to getIssueListAsArrayByIssueType(IssueType) is null, throw an IllegalArgumentException. If the issueType String is not “Bug” or
“Enhancement”, that’s fine. Return an empty list of
Issues. (A next iteration of the project could add a new type of Issue and it would work without any additional
The other methods in
IssueManager delegate to the IssueList. createNewIssueList() updates the global issueList reference to point to a new IssueList object. The old
IssueList will be garbage collected. We will assume that the user will have saved the info already (if they wanted it) before calling that operation (if they didn’t they
are out of luck in this version of the application).
addIssueToList(IssueType issueType, String summary, String note) has the same parameters as
IssueList.addIssue(IssueType issueType, String summary, String note) and the Issue(IssueType issueType, String summary, String note) constructor.
Overall Flow of Control
The sequence diagram shown below models the flow of Use Case 2, Subflow 3 to Use Case 3 and back to Use Case 2. The assumption is that an IssueList has already
been created or loaded and populated with at least one
Issue in the NewState. The flow of control in the sequence diagram is similar for other functionality. For this
flow of control, assume the selected issue is of type “Bug”.

Figure 2: Issue Manager Sequence Diagram for UC2, S3 to UC3
For Part 2 of this project, you must do white box testing via JUnit AND report the results of running your black box tests from Part 1.
Test Files
We have provided several test files that will be helpful when testing the Issue Manager.
White box testing
Your JUnit tests should follow the same package structure as the classes that they test. You need to create JUnit tests for all of the concrete classes that you create
(even inner classes). At a minimum, you must exercise every method in your solution at least once by your JUnit tests. Start by testing all methods that are not
simple getters, simple setters, or simple constructors for all of the classes that you must write and check that you are covering all methods. If you are not, write tests
to exercise unexecuted methods. You can test the common functionality of an abstract class through a concrete instance of its child.

When testing void methods, you will need to call other methods that do return something to verify that the call made to the void method had the intended effects.
For each method and constructor that throws exceptions, test to make sure that the method does what it is supposed to do and throws an exception when it should.
At a minimum, you must exercise at least 80% of the statements/lines in all
non-GUI classes except for IssueWriter, where you must have at least 60% statement/line
coverage (with
IssueWriter, 80% statement/line coverage will likely not be possible with the type of exception that you’ll be concerned with catching). Jenkins is set
up to evaluate appropriate levels of coverage for classes as described above.
You will likely cover the simple getters, setters, and constructors as part of testing more complex functionality in your system. You must have 95% method coverage
to achieve a green ball on Jenkins (assuming everything else is correct).
We recommend that you try to achieve 100% condition coverage (where every conditional predicate is executed on both the true and false paths for all valid paths in
a method) in most parts of the program.
Testing the State Pattern
Since the concrete IssueState classes are private inner classes, you will not be able to test them directly. Instead, you will need to update a particular Issue with a
Command that will cause a change of state (or not) and then check the Issue’s state and other fields to ensure the values were updated correctly.
If you want to test the id of a
Issue, make sure that you reset the counter to zero at the start of each test BEFORE creating a new Issue.
Remember that when testing an FSM, you want to test each transition out of each state. That means you must first get to the state (by issuing
Commands) and then
test the transition out (by issuing another
Command). Then you need to check that the state of the Issue is correct.
An example test scenario for testing transition VerifyingA would be the following:
1. Create a new
Issue with ENHANCEMENT issue type.
2. Check that newly created Enhancement Issue is New.
3. Issue a ASSIGN Command.
4. Check that Issue is assigned to the given owner in the Working state.
5. Issue a RESOLVE Command with a FIXED resolution.
6. Check that Issue is Verifying.
7. Issue a VERIFY Command.
8. Check that Issue is Closed.
You should create similar tests for all the other transitions and then consider different patterns of transition.
Testing the Singleton
The IssueManager is a singleton class, which means there is only one instance, and once that instance is created, that’s the instance that is used. So if one test adds
Issues to a list, then those Issues will be there for the next test. To make each test atomic so that it can run in isolation (because run order is NOT guaranteed), you
can use the
IssueManager.createNewIssueList() method to remove any issue that exists in the IssueManager. Since the issueList is the only other state (besides the
singleton instance), using that method resets the Singleton to an empty
For the
Issue’s id to work correctly, the IssueList constructor MUST reset the counter to 0 (for an empty IssueList) or to maxId + 1 for an IssueList generated by
reading from a file. Note that
IssueManager will delegate to IssueList constructors to accomplish this.
Black box testing and submission
public void setUp() throws Exception {
//Reset the Issue counter at the beginning of every test.


本网站支持淘宝 支付宝 微信支付  paypal等等交易。如果不放心可以用淘宝交易!

E-mail: [email protected]  微信:itcsdx