关键词 > COMP1406 Java代写
COMP1406 Assignment 2 Temperature & Boxes
发布时间：2025-12-24
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit
COMP1406 Assignment 2 Temperature & Boxes
Assignment 6: Category-Partition
This individual assignment has two parts. For Part I, you
must generate test case
specifications for the version of the encode utility, whose
specs are provided below, using
the category-partition method. For Part II, you will
demonstrate how some of your test
frames may be used, by developing test cases that
implement them.
Concise Specification of the encode Utility
●
NAME:
encode – encodes words in a file.
●
SYNOPSIS
encode OPT
where OPTcan be zero or more of
○
○
○
-a
(-r | -k)
-c
●
COMMAND-LINE ARGUMENTS AND OPTIONS
<
–
filename>: the file on which the encode operation has to
be performed.
a:if specified, the utility will encode all alphabetic (a-z, A-
Z) characters by
applying an Atbash Cipher (other characters remain
unchanged and the
capitalization is preserved), so ‘a’ and ‘A’ would be
encoded as ‘z’ and ‘Z’, while ‘y’
and ‘Y’ would be encoded as ‘b’ and ‘B’. This option is
always applied last.
(
-r|-k) :if specified, the utility will remove(-r) or
keep (-k) only the
alphabetic characters (capitalization insensitive) in the file
which are included in the
required . All non-alphabetic characters are
unaffected. -r and -k are
mutually exclusive.
–
c :if specified, the encodeutility will reverse the
capitalization (i.e.,
lowercase to uppercase, and uppercase to lowercase) of all
the occurrences, in the
file, of the characters specified in the required
If none of the OPT flags is specified, encode will default to
applying -c to all
letters A-Z.
●
NOTES
○
While the last command-line parameter provided is always
treated as the
filename, OPT flags can be provided in any order; no
matter the order of the
parameters, though, option -awill always be applied last.
●
EXAMPLES OF USAGE
Example 1:
encode file1.txt
(
where the content of the file is “abcXYZ”)
Reverses the capitalization of all letters. (resulting in
“ABCxyz”).
Example 2:
encode -r aZ file1.txt
Removes all instances of a, A, z and Z from the file.
Example 3:
encode -c “aeiou” -k “aeiouxyz” file1.txt
Changes all occurrences of characters ‘a’, ‘e’, ‘i’, ‘o’ and ‘u’
to uppercase, and all
occurrences of characters ‘A’, ‘E’, ‘I’, ‘O’ and ‘U’ to lowercase.
Then, removes all
letters other than ‘a’, ‘e’, ‘i’, ‘o’, ‘u’, ‘x’, ‘y’, ‘z’, ‘A’. ‘E’, ‘I’, ‘O’, ‘U’,
‘X’, ‘Y’ and ‘Z’.
Example 4:
encode -a -k abc file1.txt
Removes all letters that are not ‘a’, ‘b’, ‘c’, ‘A’, ‘B’, or ‘C’.
Then, encodes ‘a’ to ‘z’, ‘b’ to
‘
y’, and ‘c’ to ‘x’ (and the corresponding capitalized
equivalents.)
Part I
Generate between 40 and 80 test-case specifications (i.e.,
generated test frames),
inclusive, for the encode utility using the category
partition method presented in lesson
P4L2. Make sure to watch the lesson and the included
demo before getting started.
When defining your test specifications, your goal is to
suitably cover the domain of the
application under test. Make sure to use constraints (error
and single), selector
expressions (if) and properties appropriately, rather than
eliminating choices, to
keep the number of test cases within the specified
thresholds. This also should
include relevant erroneous inputs and input combinations.
Just to give you an
example, if you had to test a calculator, you may want to
cover the case of a division by
zero. Do not manually generate combinations of inputs as
single choices. Use
multiple categories and choices with necessary constraints
to cause the tool to generate
combinations of the inputs. Using the calculator example,
you would not offer choices of
“
add.”, “multiply.”, and also “add and multiply.” in a single
category.
Note that the domain is constrained to the java
application under test, and not the
command line itself. So, you should not be concerned with
the way command-line
arguments are parsed by the shell and may assume that
anything the command line would
reject will not reach the application. The command line will
not validate input according to
the application’s requirements. However, it will take care of
problems such as enclosing
strings in quotation marks and will not allow null as an
input argument. So, you must test
for invalid input arguments, but do not need to test for
errors parsing the input
arguments themselves before they are sent to the java
application. The sample tests
in Part II will demonstrate how input arguments would be
sent to your application, for
further clarification.
Please also keep in mind that you are only required to
specify test inputs, but you do not
have to also specify the expected outcome for such inputs
in Part I. It is therefore OK if you
don’t know how the system would behave for a specific
input. Using the same calculator
example, you could test the case of a division by zero even
if you do not know how exactly
the calculator would behave for that input.
Tools and Useful Files
You will use the tsltool to generate test frames starting
from a TSL file, just like we did in
the demo for lesson P4L2. A version of the tsltool for
Linux, Mac OS X, and Windows,
together with a user manual, are available at:
●
●
●
●
●
TSLgenerator-manual.txt
TSL generator for Linux
TSL generator for Mac OS
TSL generator for Windows 8 and newer
TSL generator for Windows XP and earlier
We are also providing the TSL file for the example we saw
in the lesson, cp-example.txt, for
your reference.
Important:
●
These are command-line tools, which means that you have
to run them from the
command line, as we do in the video demo, rather than by
clicking on them.
●
On Linux and Mac systems, you may need to change the
permissions of the files to
make them executable using the chmod utility. To run the
tool on a Mac, for
instance, you should do the following, from a terminal:
chmod +x TSLgenerator-mac
.
/TSLgenerator-mac
●
You can run the tsltool as follows:
Where is the specific tool for your architecture, and
the command-line flags
have the following meaning:
–
-manpage Prints the man page for the tool.
–
be
c
Reports the number of test frames that would
generated, but does not actually produce them.
Outputs to standard output.
–
–
s
o outfile Outputs to file outfile, unless the -s
option is also used.
●
If you encounter issues while using the tool, please post a
public question on Piazza
and consider running the tool on the VM provided for the
class or on a different
platform (if you have the option to do so).
Instructions to commit Part I
●
Create a directory “Assignment6” in the personal GitHub
repo we assigned to you.
●
Add to this new directory two text files for Part I:
○
○
catpart.txt: the TSL file you created.
catpart.txt.tsl: the test specifications generated by the
tsltool when
run on your TSL file.
●
Commit and push your files to GitHub. (You can also do
this only at the end of Part II,
but it is always safer to have intermediate commits.)
Part II
To demonstrate how your test frames resulting from the
category partition may be used to
cover the domain of the application with appropriate tests,
and validate your work in Part
I, you will use your test specifications and a provided
interface to prepare 15 actual JUnit
tests (as discussed in the lesson on the category-partition
method, each test frame is a test
spec that can be instantiated as a separate concrete test
case). To do so, you should
perform the following steps:
●
●
Download archive Assignment6.tar.gz
Unpack the archive in directory “Assignment6”, which you
created when completing
Part I of the assignment. Hereafter, we will refer to this
directory as
. After
unpacking, you should see the following structure:
○
This is a skeleton of the Main class of the encode utility,
which is provided so
that the test cases for encode can be compiled. It contains
an empty main
method and a method usage, which prints on standard
error a usage message
and should be called when the program is invoked
incorrectly. In case you
wonder, this method is provided for consistency in test
results.
○
This is a test class with a few test cases for the encode
utility that you can use
as an example and that correspond to the examples of
usage of encode that
we provided. In addition to providing this initial set of
tests, class MainTest
also provides some utility methods that you can
leverage/adapt and that may
help you implement your own test cases:
■
■
■
File createTmpFile()
Creates a File object for a new temporary file in a platform
independent way.
File createInputFile*()
Examples of how to create, leveraging method
createTmpFile,
input files with a given content as inputs for your test
cases.
String getFileContent(String filename)
Returns a Stringobject with the content of the specified
file, which
is useful for checking the outcome of a test case.
○
This is an empty test class in which you will add your test
cases, provided for
your convenience.
●
Use 15 different test frames from Part I to generate 15
additional JUnit test cases for
the encode utility and put them in the test class
MyMainTest(i.e., do not add your
test cases to class MainTest). For ease of grading, please
name your test cases
encodeTest1, encodeTest2, and so on. Each test should
contain a concise
comment that indicates its purpose and which test frame
the test case implements.
Use the following format for your comments, before each
test:
// Purpose:
test>
// Frame #:
/encode) to the
I>
Each test should obviously suitably implement a unique
referenced test frame.
Your test frames should contain enough clear information
to create relevant test
cases whenever a test creator uses input that fulfils the
criteria in the test frame. If
you cannot implement your test frames as useful JUnit
tests, or find yourself
needing to add information or edge cases, you should
revisit Part I. Extending
the calculator example, if your test specified a numerical
input, and you decided that
you need both negative and positive numbers in your test
cases, you should make
sure that is reflected in your test cases from Part I, rather
than assuming that a
tester would, on their own, use negative numbers in some
cases and positive in
others.
If you are uncertain what the result should be for a test,
you may make a
reasonable assumption on what to use for your test oracle.
While you should
include a test oracle to clarify your intended test, and your
tests must clearly reflect
the input specifications in your test frames, we will not
grade the accuracy of the
test oracle itself.
Feel free to reuse and adapt, when creating your test
cases, some of the code we
provided in the MainTestclass (without copying the
provided test cases verbatim,
of course, which also implies that you should not
implement test frames that
correspond exactly to the test cases we provided). Feel
also free to implement your
test cases differently. Basically, class MainTestis provided
for your convenience
and to help you get started. Whether you leverage class
MainTestor not, your test
cases should assume (just like the test cases in MainTest
do) that the encode utility
will be executed from the command line, as follows:
java -cp edu.gatech.seclass.encode.Main
Important: Do not implement the encode utility, but only
the test
cases for it. This also means that most, if not all of your
test cases
will fail, which is fine.
Instructions to commit Part II and submit the assignment
●
Commit and push your code (i.e., the Java files in directory
main branch of your assigned individual repository.
●
Paste only the single, final commit ID for your submission
on Canvas, as usual.
