Course code and name: ISYS1118 Software Engineering Fundamentals

Assessment name: Unit & Acceptance Testing

Assessment type: Individual

Submission Type: Written report and code submission

Report Length: Less than or equal to 3 pages (but not more than 3 pages)
Assessment Marks: 25

Grading Rubric: Included (added at the end of the specifications)

Learning Objectives Assessed

This assessment evaluates the following CLOs:

• CLO 1: Explain and apply the main aspects of software engineering.

• CLO 2: evaluate requirements for a software system
• CLO 6: recognise and describe current trends in the area of software engineering
• CLO 7: Design and carry out tests using various testing techniques and tools.

Authentic Assessment Principles

This assessment covers 4 key AA principles

• Challenge
• Deep learning and critical reflection
• Artefact or performance
• Transferable knowledge and skills with real-world application

Assessment Details
In this assessment, you will need to implement the functionalities and verify your code using unit
testing to ensure specifications are met. IMPORTANT: If you believe that the provided code may
include bugs and is incomplete, then you can fix them ONLY if it is necessary for your solution.
This is TDD (Test Driven Development). You write your code first and then code enough to make
the test pass, and nothing more.

Naming Convention

Use the following naming convention for your tests:

MethodName_ExpectedBehavior_StateUnderTest

For example:

isValid_False_IfMandatoryFieldsMissing
calculateBonus_ThrowsException_IfNotValidEmployee
Warning: No Dummy Tests

The use of "dummy tests" is not allowed. If you have dummy tests or dummy returns in your
classes you will fail the assignment.

What is a dummy test?

This test will always pass, regardless of the content of the classes (model). In short words, a
dummy test tests nothing! Any type of dummy test is forbidden and will make you fail the
assignment.

// This is a dummy test in java

public void isValid_False_IfMandatoryFieldsMissing() {
assertTrue(true);
}

What are dummy returns?

This refers to hard-coding a return in a class and you only test that very same return. This way,
the test will always pass, but tests nothing!

Assessment criteria
You’ll be assessed on the following activities:
• Activity 1 – Implement and Test software function (64%)
• Activity 2 - Design user stories and clearly communicate criteria (20%)
• Activity 3 - Explain the type of software maintenance (16%)

For more details, check the rubric attached below:

Template Code and Submission: Code submissions are accepted via GitHub only. The base
code is made available through GitHub Classroom https://classroom.github.com/a/hZ53JpxA
(Note: Same code is also available on canvas -> assignment 4)

Activity 1 – Implement and Test software function (Marks 16)

Note: Students are referred to the pre-recorded lectures of week 9 and practical activities of week
11 that contain all the information needed to address this activity

The folders 'java/model' and 'java/utils' have some classes with default/fixed returns. These
classes are skeleton code that may not represent the real-world solution, but represents a real-
world scenario. You are only required to implement the function addCustomertoService() in
class Service based on the below-mentioned instructions. You can change the skeleton only if it
is necessary and these should be justified in the written report (minor changes are acceptable
e.g., changing return values from methods, major changes to the base skeleton code or addition
of new methods representing new features are not allowed). Note: The quality of the code you
write will influence your final marks of the activity.

There is a class in 'test/java/*'. You need to fill the tests according to the following
instructions. Note: name the tests using the naming convention defined above.

What to implement?
Implement (marks 6) and test (marks 10) Service.addCustomertoService() that respects the
following:
• Get the number of services a customer is currently using
• A customer cannot hold more than 3 services
• Throws an exception if a customer is already using the same service
• Get the number of customers associated with the service offered by a franchise
• A service offered by a franchise cannot have more than 500 customers
• If the above constraints are met then add service for the customer, return true and make
any changes to the attributes that are affected by this change. If not then return false

You are expected to complete the following activities here:

• Write test cases for Service.addCustomertoService()

• Each test criteria must be in an independent test method
• Initialize the test object with setUp method. You are expected to use a proper unit testing
initialisation
• The test cases should be added to test/java/AddCustomertoService
• You can correct any bugs in the skeleton code that doesn’t involve any changes to the
skeleton code
• All test units should be commented in the code to describe what conditions are being
tested e.g. “This method test the division method for numerator >0 and denominator =0”

Your response addresses CLO 1, 2

Activity 2 – Design user stories and clearly communicate criteria (Marks 5)

Note: Students are referred to the pre-recorded lectures of week 10 and practical activities of week
12 that contain all the information needed to address this activity

Using the scenario/code provided in activity 1, create 2 user stories. These user stories should
be accompanied by the acceptance criteria. The acceptance criteria for one user story should
be based on GWT (Given When Then) and the acceptance criteria for the second user story
should be based on rule-oriented approach (follow the guidelines discussed in the tutorials). You
can make assumptions about the system, but this needs to be explicitly mentioned in the report

Your response addresses CLO 6, 7

Activity 3 – Explain the type of software maintenance (Marks 4)

Note: Students are referred to the pre-recorded lectures of week 11 that contain all the information
needed to address this activity

Assume that the code presented in this assessment has been delivered to the client as an
online/web system. Identify the type of software maintenance required for the following
scenarios. Your recommendation of the maintenance type should be accompanied by reasoning
(i.e., why the recommended maintenance type applies to the given scenario?)

a) The system is unstable on Safari browser

b) The customer is not being added to any service
c) Store more information about the services and customers apart from basic names and
IDs.
 d) Refactoring and restructuring the code

Your response addresses CLO 1, 2

Submission Guide:
• Push your code to the GitHub respoistory created by accessing the assignmnet created
using GitHub Classroom (https://classroom.github.com/a/hZ53JpxA)
• The provided code already has sub-folders, so DON'T create new sub-folders or change
the structure of the code.
• All the main code (containing the functionality-classes) are located in
folder "/assigment4_code(this is the name of your repository created on GitHub
Classroom)/src/main/java/model". Similarly, all the test cases should be located in
folder "/assigment4_code(this is the name of your repository created on GitHub
Classroom)/src/test/java/model"

Late work:
Unless special consideration has been granted, the late penalty is 10% of the total mark (25 x
10/100 = 2.5 marks) for the assessment per day late for up to 5 days late (so the maximum late
penalty is 50%). Submissions more than 5 days late are not accepted.
 RMIT Classification: Trusted

Rubric
Criteria Ratings Pts
Activity 1 16 to >14 Pts 14 to >13.5Pts 13.5 to >11 Pts 11 to >8 Pts 8 to >0 Pts 16 pts
HIGH DISTINCTION DISTINCTION Credit Pass Fail
Implement The requested method is The requested method is The requested method is The requested method is The method to be
and Test correctly implemented. logically implemented. largely correctly somewhat correctly implemented is not
software Flawless testing (borderline Professional testing implemented. Correct testing implemented (minor errors). implemented or
function and common cases, with the (borderline and common (borderline and common Incomplete testing (not all implementation is
perfect organisation), code cases, with the acceptable cases, but the proportion borderline and common wrong/incorrect.
quality and organisation. All organisation), code quality may be off, or missing many cases are tested). Some There are try/catches
tests pass. No dummy tests or and organisation. All tests of them), code quality, and tests may be failing, there in the testing
returns. There are no try/catch pass. No dummy tests or organisation. All tests pass. may be problems with methods. -
blocks on the tests, the returns. There are no No dummy tests or returns. annotations, or Consistently incorrect
student is using Junit5, the try/catch blocks on the There are no try/catch organisation. The selection of asserts. -
variables are properly tests, the student is using blocks on the tests (there distribution of assert/test is Very poor distribution
initialised, and there is correct Junit5, the variables are may be errors), the student not adequate. Tests don't of asserts in test
distribution of asserts per test properly initialised, and is using Junit5, the variables follow the requested methods, and
method. All concepts are used there is correct distribution are properly initialised, and naming convention. There incorrect use of
consistently and properly. All of asserts per test method. there is the correct are no try/catch blocks on naming notations.
annotations are well used. The All concepts are used distribution of assets per test the tests, the student is The variables are
best assert for each case is properly but there may be method (but this may be using Junit5. The variables consistently initialised
used. The student created a some mistakes. All inconsistent). All concepts may be mixed (some the wrong way. The
professional test set that annotations are well used. are used, but they may be properly initialised, others testing set is vastly
minimises the number of tests The best assert for each inconsistent or have minor not). Concepts are incomplete, or the
written but also covers a wide case is used, but there problems. All annotations inconsistently used, and student tested only a
range of borderline/edge and may be better options. The are well used. The best there is a poor/convoluted single type of cases
common cases. Most relevant student created a assert for each case is used. choice about which assert (or too few of the
cases are tested, providing professional test set that The student created an to use (e.g., there was a other). The asserts
excellent insights. There are covers a wide range of acceptable test set but better/more straightforward are consistently used
no repeated tests. borderline/edge and doesn’t fully cover a nice solution). Some the wrong way. - The
common cases (but there range of borderline/edge annotations may be student is using
may be redundant cases or and common cases. Most missing. The test set that alternative ways to
missing cases). Most relevant cases are tested, minimises is either execute the test set
relevant cases are tested, providing major points. redundant or heavily that are wrong. There
providing some good There are repeated/missing incomplete or mixes both are dummy tests.
insight. tests. cases. However, there
must be both
borderline/edge and
common cases. Some
 RMIT Classification: Trusted

relevant cases are tested.

There are repeated tests.
Activity 2 5 to >4 Pts 4 to >3.5Pts 3.5 to >3 Pts 3 to >2.5 Pts 2.5 to >0 Pts 5 pts
HIGH DISTINCTION DISTINCTION Credit Pass Fail
Design user Excellent selection of Good selection of Average selection of Sound selection of The requested
stories and scenarios (effectively aligned scenarios (mostly aligned scenarios for acceptance scenarios for acceptance acceptance criteria
clearly with the given system) for with the given system) for criteria (somewhat aligned criteria (few aligned with are incomplete or not
communicate acceptance criteria and perfect acceptance criteria and with the given system). The the given system). The reported. Contains
criteria writing. Clear concepts of well-written. The GWT and scenario has minor errors criteria have many errors major errors,
GWT and rule-based rule-based acceptance but is somewhat complete. and are somewhat incomplete parts,
acceptance criteria. The criteria are largely correct Some criteria may be incomplete or incorrect. incorrect concepts or
explanation is complete and and complete. Most are properly worded, and may Few criteria may be other mistakes.
correct. All criteria are properly properly and adequately include sufficient detail. properly worded, and may
and professionally worded. worded but have Minor errors or missing include brief detail. Many
The GWT and rule-based mistakes/inaccuracies. The information in the reported errors or missing
criteria are fully detailed. No GWT and rule-based acceptance criteria. information in the reported
error or missing information in criteria are largely detailed. acceptance criteria.
the reported acceptance No error or missing
criteria. information in the reported
acceptance criteria.
Activity 3 4 to >3.5 Pts 3.5 to >3 Pts 3 to >2.5 Pts 2.5 to >2 Pts 2 to >0 Pts 4 pts
HIGH DISTINCTION DISTINCTION Credit Pass Fail
Explain the Demonstrated clear Demonstrated logical A somewhat clear The explanation portrays Poor understanding
type of understanding of software understanding of software understanding of the few confused of the software
software maintenance concepts. maintenance concepts. software maintenance understanding of the maintenance concept.
maintenance Software maintenance type The software maintenance concept. Software software maintenance The explanation is
was recommended for all 4 type was recommended for maintenance type was concept. Software incomplete or not
scenarios. All reasoning all 4 scenarios. Most recommended for ≥3 maintenance type was correct. The
provided for each reasoning provided for scenarios. Some reasoning recommended for ≥2 reasoning is not
recommendation is valid, each recommendation is provided for each scenarios. The reasoning logical or is
logical, correct, and free of valid, logical, and correct recommendation is largely provided for each erroneous. The
errors. The response is easy with minor errors. The correct, but with a few minor recommendation is response is difficult to
to follow and well-explained, response is easy to follow, errors. The response is somewhat correct, but with follow with limited or
providing excellent insights. providing some good somewhat easy to follow, many minor errors. The no discussion, lacking
insight. providing major points. response is somewhat easy major points.
to follow, but the discussion
is limited and not always
providing major points.