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.

Rubric
Criteria Ratings
Activity 1 16 to >14 Pts
HIGH DISTINCTION
Implement The requested method is
and Test correctly implemented.
software Flawless testing (borderline
function and common cases, with the
perfect organisation), code
quality and organisation. All
tests pass. No dummy tests or
returns. There are no try/catch
blocks on the tests, the
student is using Junit5, the
variables are properly
initialised, and there is correct
distribution of asserts per test
method. All concepts are used
consistently and properly. All
annotations are well used. The
best assert for each case is
used. The student created a
professional test set that
minimises the number of tests
written but also covers a wide
range of borderline/edge and
common cases. Most relevant
cases are tested, providing
excellent insights. There are
no repeated tests.
RMIT Classification: Trusted
14 to >13.5Pts
DISTINCTION
The requested method is
logically implemented.
Professional testing
(borderline and common
cases, with the acceptable
organisation), code quality
and organisation. All tests
pass. No dummy tests or
returns. There are no
try/catch blocks on the
tests, the student is using
Junit5, the variables are
properly initialised, and
there is correct distribution
of asserts per test method.
All concepts are used
properly but there may be
some mistakes. All
annotations are well used.
The best assert for each
case is used, but there
may be better options. The
student created a
professional test set that
covers a wide range of
borderline/edge and
common cases (but there
may be redundant cases or
missing cases). Most
relevant cases are tested,
providing some good
insight.
13.5 to >11 Pts
Credit
The requested method is
largely correctly
implemented. Correct testing
(borderline and common
cases, but the proportion
may be off, or missing many
of them), code quality, and
organisation. All tests pass.
No dummy tests or returns.
There are no try/catch
blocks on the tests (there
may be errors), the student
is using Junit5, the variables
are properly initialised, and
there is the correct
distribution of assets per test
method (but this may be
inconsistent). All concepts
are used, but they may be
inconsistent or have minor
problems. All annotations
are well used. The best
assert for each case is used.
The student created an
acceptable test set but
doesn’t fully cover a nice
range of borderline/edge
and common cases. Most
relevant cases are tested,
providing major points.
There are repeated/missing
tests.
11 to >8 Pts
Pass
The requested method is
somewhat correctly
implemented (minor errors).
Incomplete testing (not all
borderline and common
cases are tested). Some
tests may be failing, there
may be problems with
annotations, or
organisation. The
distribution of assert/test is
not adequate. Tests don't
follow the requested
naming convention. There
are no try/catch blocks on
the tests, the student is
using Junit5. The variables
may be mixed (some
properly initialised, others
not). Concepts are
inconsistently used, and
there is a poor/convoluted
choice about which assert
to use (e.g., there was a
better/more straightforward
solution). Some
annotations may be
missing. The test set that
minimises is either
redundant or heavily
incomplete or mixes both
cases. However, there
must be both
borderline/edge and
common cases. Some
Pts
8 to >0 Pts 16 pts
Fail
The method to be
implemented is not
implemented or
implementation is
wrong/incorrect.
There are try/catches
in the testing
methods. -
Consistently incorrect
selection of asserts. -
Very poor distribution
of asserts in test
methods, and
incorrect use of
naming notations.
The variables are
consistently initialised
the wrong way. The
testing set is vastly
incomplete, or the
student tested only a
single type of cases
(or too few of the
other). The asserts
are consistently used
the wrong way. - The
student is using
alternative ways to
execute the test set
that are wrong. There
are dummy tests.

Activity 2 5 to >4 Pts
HIGH DISTINCTION
Design user Excellent selection of
stories and scenarios (effectively aligned
clearly with the given system) for
communicate acceptance criteria and perfect
criteria writing. Clear concepts of
GWT and rule-based
acceptance criteria. The
explanation is complete and
correct. All criteria are properly
and professionally worded.
The GWT and rule-based
criteria are fully detailed. No
error or missing information in
the reported acceptance
criteria.
Activity 3 4 to >3.5 Pts
HIGH DISTINCTION
Explain the Demonstrated clear
type of understanding of software
software maintenance concepts.
maintenance Software maintenance type
was recommended for all 4
scenarios. All reasoning
provided for each
recommendation is valid,
logical, correct, and free of
errors. The response is easy
to follow and well-explained,
providing excellent insights.
RMIT Classification: Trusted
4 to >3.5Pts
DISTINCTION
Good selection of
scenarios (mostly aligned
with the given system) for
acceptance criteria and
well-written. The GWT and
rule-based acceptance
criteria are largely correct
and complete. Most are
properly and adequately
worded but have
mistakes/inaccuracies. The
GWT and rule-based
criteria are largely detailed.
No error or missing
information in the reported
acceptance criteria.
3.5 to >3 Pts
DISTINCTION
Demonstrated logical
understanding of software
maintenance concepts.
The software maintenance
type was recommended for
all 4 scenarios. Most
reasoning provided for
each recommendation is
valid, logical, and correct
with minor errors. The
response is easy to follow,
providing some good
insight.
3.5 to >3 Pts
Credit
Average selection of
scenarios for acceptance
criteria (somewhat aligned
with the given system). The
scenario has minor errors
but is somewhat complete.
Some criteria may be
properly worded, and may
include sufficient detail.
Minor errors or missing
information in the reported
acceptance criteria.
3 to >2.5 Pts
Credit
A somewhat clear
understanding of the
software maintenance
concept. Software
maintenance type was
recommended for ≥3
scenarios. Some reasoning
provided for each
recommendation is largely
correct, but with a few minor
errors. The response is
somewhat easy to follow,
providing major points.
relevant cases are tested.
There are repeated tests.
3 to >2.5 Pts 2.5 to >0 Pts 5 pts
Pass Fail
Sound selection of The requested
scenarios for acceptance acceptance criteria
criteria (few aligned with are incomplete or not
the given system). The reported. Contains
criteria have many errors major errors,
and are somewhat incomplete parts,
incomplete or incorrect. incorrect concepts or
Few criteria may be other mistakes.
properly worded, and may
include brief detail. Many
errors or missing
information in the reported
acceptance criteria.
2.5 to >2 Pts 2 to >0 Pts 4 pts
Pass Fail
The explanation portrays Poor understanding
few confused of the software
understanding of the maintenance concept.
software maintenance The explanation is
concept. Software incomplete or not
maintenance type was correct. The
recommended for ≥2 reasoning is not
scenarios. The reasoning logical or is
provided for each erroneous. The
recommendation is response is difficult to
somewhat correct, but with follow with limited or
many minor errors. The no discussion, lacking
response is somewhat easy major points.
to follow, but the discussion
is limited and not always
providing major points.