[SOLVED] Cs6300 individual project: transformtxt deliverable 1 2025

In this project, you will be developing a Java application, transformtxt, using an agile, test-driven development process across multiple deliverables. For this assignment you will use version 17 of the Java Development Kit. You will receive one grade for the entire project, but each deliverable must be completed by its own due date and all deliverables will contribute to the overall project grade.

transformtxt is a command-line utility written in Java with the following specification:

transformtxt allows for simple text manipulation of the contents of a file.

transformtxt [OPTIONS] FILE

The program transformtxt performs basic text transformation on the lines of text from an input file. It is invoked as a command-line tool using the syntax described above, after compilation. The program writes the transformed text to the standard output and errors or usage messages to the standard error without modifying the input file. The FILE parameter is required and must be the last parameter as shown above. The only options allowed in the program, which are optional, delimited by the left [ and right ] brackets, may be provided in any order and are described as follows:

The last command-line parameter provided is always treated as the filename, as shown in the syntax section, while OPTIONS flags can appear in any order and parsed as they appear from left to right. This means that the following two commands are equivalent when executed on the command line:

In the above examples, (Example 1) parses -x first, then -t, and finally input.txt while (Example 2) parses -t first, then -x, and finally input.txt. These two examples will result in the same output (assuming that the same input.txt is used for both) because the parsing of options is independent of their execution order. The order of execution for each option is given in the diagram below (note that the colors and border lines are there for ease of viewing):

The above diagram of the execution order of options can also be described as follows:

Usage: transformtxt [-s num | -x | -g | -r old new | -t length | -w spacing ] FILE

 

 

 

The cases below show scenarios where transformtxt shall result in an error according to a specific option.

 

The examples described here can also be seen in JUnit 5 form on the MainTest.java file provided to you in the below sections. In the following, “↵” represents a newline character.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This part of the document is provided to help you track where you are in the individual project. This section will be updated in future deliverables.

Provided

Expected

Provided: TBD

Expected: TBD

Provided: TBD

Expected: TBD

Deliverable 1 is split up in two parts: Part I and Part II. Follow the instructions for each of the parts as described below.

Your task for this deliverable is to generate 50 to 90 (inclusive) test frames for the transformtxt utility using the category-partition method presented in lesson P4L2. Make sure to watch the lesson and demo before getting started.

When defining your test specifications, your goal is to suitably cover the domain of the application under test, including relevant erroneous input and input combinations. For example, if you were testing a calculator, you may want to cover the case of division by zero.

Do not manually generate combinations of inputs as single choices. Instead, use multiple categories and choices with necessary constraints for the tool to generate meaningful combinations. Using the calculator example, you should not offer choices “add”, “multiple”, and also “add and multiply” in a single category – an example of what not to do can be found in calculator-manual-combinations.txt. In particular, 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 50 to 90 inclusive range.

The domain for this assignment is the Java application, so anything that the shell would reject, such as unmatched double quotes, will not reach the application. This means that you must test for invalid input arguments (such as Example 3 above), but you don’t need to test for errors involving parsing the command-line arguments before they’re sent to the Java application. In addition, you may assume that main will be called with a valid args array, meaning that values like null will not be passed.

We are in the process of rewriting the TSLgenerator. For this semester, we have a portion of this rewrite available to students called the TSLChecker, which is optional, but highly recommended to use. The TSLChecker is a tool that will check for errors that are not normally caught in the TSLgenerator for some catpart files.

If you choose to use this tool, the recommended use is to run the tslchecker on your catpart file before you run the TSLgenerator.

To run the tslchecker, pass it the path to your catpart file as so:

./tslchecker path/to/catpart.txt

The tslchecker is available for the following operating systems:

You will use the TSLgenerator tool to generate test frames starting from a TSL file, just like we did in the demo for lesson P4L2. Versions of the TSLgenerator for Linux, Mac OS, and Windows, together with a user manual, are available at:

We are also providing the TSL file for the example used in the lesson, cp-example.txt, for reference, as well as an example for explaining <n/a> values, tsl-na-example.md.

Since the TSL generator is a command-line tool, it must be run from the command line, as we do in the video demo, rather than by clicking on them. The syntax for running the tool is

<tsl> [–manpage] [-cs] infile [-o outfile]

where <tsl> is the name of the TSLgenerator executable and infile is the input file to the TSL program, i.e., the catpart.txt file. You can find out more information by running the tool with the –manpage command, which prints the manual of the TSL generator^[1].

If you encounter issues while using the tool, please post a public question on Ed Discussion and consider running the tool on a different platform, if you have the option to do so. For reference, Gradescope will execute the tool on a Linux platform.

 

In this second part of the deliverable, you will create actual test cases implementing the test specifications you created in Part I. As discussed in the lesson on the category-partition method, each test frame is a test specification that can be instantiated as an individual concrete test case. To do so, you should perform the following tests:

This is a skeleton of the Main class of the transformtxt utility, which we provide so that the test cases for transformtxt can be compiled. It contains an empty main method and a method usage, which prints, on standard error, a usage message that 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 transformtxt utility that you can use as an example; it corresponds to the examples of usage of transformtxt that we provided. In addition to providing this initial set of tests, class MainTest also provides some utility extensions and methods that you can leverage/adapt and that may help you implement your own test cases. We encourage you to use the methods to ease your design process.

This is an empty test class in which you will add your test cases, provided for your convenience.

This is a JUnit 5 extension class to facilitate capturing the standard output and standard error, which are needed to test the transformtxt application. It is used on the MainTest.java file for reference and provides two methods to capture output from Main.

JUnit 5 library to be used for the assignment.

// Frame #: <test case number in file catpart.txt.tsl>

Your test frames should contain enough information to create relevant test cases. If you cannot implement your test frames as useful JUnit tests (e.g., because the test frames do not provide enough information), you should revisit Part I. Extending the calculator example, if your test frame specified a numerical input, and you realized that you should use both negative and positive numbers in your JUnit test case, you should revise your categories and choices so that this is reflected in your test frames.

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, 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 MainTest class. MainTest is provided for your convenience and to help you get started. Whether you leverage the MainTest class or not, your test cases should assume (just like the test cases in MainTest do) that the transformtxt utility will be executed from the command line, as follows:

java -cp <classpath> edu.gatech.seclass.transformtxt.Main <arguments>

For this deliverable, do not implement the transformtxt utility, but only the test cases for it. This means that most, if not all of your test cases will fail, which is expected and fine.

 

javac -cp lib/* -d classes src/edu/gatech/seclass/transformtxt/*.java test/edu/gatech/seclass/transformtxt/*.java

java -cp classes:lib/* org.junit.platform.console.ConsoleLauncher –select-class edu.gatech.seclass.transformtxt.MyMainTest^[3]

submission.txt

 

 

 

As soon as you submit, Gradescope will verify your submission by making sure that your files are present and in the correct location, as well as a few additional minor checks.^[4] If you pass all of these checks, you will see a placeholder grade of 10 and a positive message from Gradescope. Otherwise, you will see a grade of 0 and an error message with some diagnostic information. Please note that:

If you need clarification or have questions regarding Gradescope output, please post privately on Ed Discussion (we will make it public if appropriate) and make sure to add a link to the Gradescope results and any information that may be relevant.

The bottom line is that, to make the interaction efficient, you should make your posts as self-contained and easy-to-check as possible. The faster we can respond to the posts, the more students we can help.

 

Answer: In fairness to everyone, we cannot discuss future deliverables. You will have to wait to find out the details of deliverable 2 when it’s released.

Answer: No, for part 2 you can only use the test frames that were generated in part 1.

Answer: Yes, the file is also an input to the program, so it should be considered when testing.

Answer: Although there are no restrictions on your test suite design, testing the limits of data types and file sizes is out of the scope for this assignment.

Answer: Yes, that’s no problem. This is expected since the main method is empty, so most tests won’t pass.

Answer: Yes, you may (and are encouraged to) use the example test cases to devise your own, in addition to using the structure and test methods provided.

^[1] 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

^[2] On some platforms, you may need to first create directory “classes”.

^[3] If using a Windows-based system, you may need to run
java -cp “classes;lib/*” org.junit.platform.console.ConsoleLauncher
–select-class edu.gatech.seclass.transformtxt.MyMainTest instead.

^[4] Although we tested the checker, it is possible that it might not handle correctly some corner cases. If you receive feedback that seems to be incorrect, please contact us on Ed Discussion.