[SOLVED] CS6300 Project- transformtxt Deliverable 1 2025

CS6300 Individual Project: transformtxt Deliverable 3 Solution link

Project Goals

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.

Specification

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

Summary

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

Syntax

transformtxt [OPTIONS] FILE

Description

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:

Option	Description
-s <num>	Skip Lines: Skip the lines based upon the supplied parameter, num. The parameter num can only be 0 or 1. 0 is considered to skip every even line, and 1 is to skip every odd line. All files start with line 1.
-x	Remove Empty Lines: Removes all empty lines from the input file. This option takes no parameters.
-g	Global Replace: Replaces all occurrences of substring old in each line with string new. This option is used with the -r flag only.
-r <old> <new>	Replace substrings: Replaces the first instance of substring old in each line with string new. The search is case-sensitive.
-w <spacing>	Remove Whitespace: Removes whitespace from lines of the input file based on the specified spacing. The spacing parameter can be one of three case-sensitive string values: “leading”, “trailing”, or “all”. The “leading” string parameter removes whitespace at the beginning of each line, “trailing” removes whitespace at the end of each line, “all” removes all whitespace from the line (beginning, middle, and end). This option is mutually exclusive with -t.
-t <length>	Truncate Lines: Truncate each line to the specified maximum length. The length parameter is an integer between 0 and 100 (inclusive). This option is mutually exclusive with -w.

Order of execution

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:

Example 1	transformtxt -x -t 20 input.txt
Example 2	transformtxt -t 20 -x input.txt

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:

1. If -s is present, then lines are skipped based on the parameter value ( 0 or 1).
2. If -x is present, then all empty lines shall be removed.
3. If -g is present, then -r should be followed and replace all old strings of the input file.
4. If -r is present without -g, only the first occurrence of the old substring on each line should be replaced.
5. If -t or -w is present, then lines shall be modified according to their respective parameter.

Requirements

• To keep this application simple, all errors shall result in the display of the standard usage message:

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

• An empty input file shall produce an empty output. The Examples section below shows a case of an empty input file.

 

Java

• You shall assume that the command line parameter strings will not contain newline characters (\r, \n, \r\n) as the behavior of the program would be platform dependent and may result in error during grading. Therefore there should be no test cases using these values as option parameters. Additionally, you may assume that your application will be called with valid String[]
• Make sure not to make calls to exit() within your tests, as that creates problems for JUnit.

 

Options

• If options are repeated, only their last occurrence is applied. The Examples section below shows a case of repeated options.

 

Program errors

FILE errors

• The last line of a non-empty input file must be terminated by a newline. If the non-empty input file does not terminate in a newline, the program shall generate an error.
• The last parameter is always assumed to be a path to the input file. Omitting it shall result in an error otherwise.

Option errors

• All parameters of program options are required and shall result in an error if omitted. This means that parsing an option that should include parameters but doesn’t should result in an error. The Examples section below shows a case of missing option parameters.
• Any unrecognized option shall result in an error.

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

Options	Error Cases
-s	●     Providing an integer outside of the inclusive range 0 to 1 as the skip parameter. ●     Providing a non-integer as the skip parameter.
-g	●     Specifying option -g without -r.
-r	●     Providing an empty string as the old parameter.
-t	●     Specifying options -t with -w. ●     Providing a non-integer as the maximum length. ●     Providing an integer outside of the inclusive range 0 to 100  as the maximum length.
-w	●     Specifying options -w with -t ●   Providing a parameter outside of the allowed values (“leading”, “trailing”, or “all”).

 

Examples of Usage

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.

Example 1
transformtxt sample.txt
input sample.txt
stdout	nothing sent to stdout
stderr	nothing sent to stderr

 

Example 2
transformtxt -x -w all sample.txt
input sample.txt	↵
stdout	nothing sent to stdout
stderr	nothing sent to stderr

 

Example 3
transformtxt -s 2 sample.txt
input sample.txt	Hello, World.↵ Hello, World.↵ Hello, World.↵
stdout	nothing sent to stdout
stderr	Usage: transformtxt [-s num | -x | -g | -r old new | -t length | -w spacing ] FILE↵

 

 

 

Example 4
transformtxt -s 1 sample.txt
input sample.txt	Okay, here is how this is going to work.↵ No shouting!↵ Does that make sense?↵ Alright, good meeting.↵
stdout	No shouting!↵ Alright, good meeting.↵
stderr	nothing sent to stderr

 

Example 5
transformtxt -t 10 sample.txt
input sample.txt	Okay, here is how this is going to work.↵ No shouting!↵ Does that make sense?↵ Alright, good meeting.↵
stdout	Okay, here↵ No shoutin↵ Does that ↵ Alright, g↵
stderr	nothing sent to stderr

 

 

 

Example 6
transformtxt -w trailing sample.txt
input sample.txt	This is a normal text file.     ↵ Perhaps too normal…    ↵ Or not normal at all.↵
stdout	This is a normal text file.↵ Perhaps too normal…↵ Or not normal at all.↵
stderr	nothing sent to stderr

 

Example 7
transformtxt -g -r red green sample.txt
input sample.txt	I love red apples. I love all red fruits.↵ I love red hats. I love all red clothes.↵
stdout	I love green apples. I love all green fruits.↵ I love green hats. I love all green clothes.↵
stderr	nothing sent to stderr

 

 

 

Example 8
transformtxt -x -w all sample.txt
input sample.txt	One,    two,    three,        ↵ ↵ ↵ Ten↵
stdout	One,two,three,↵ Ten↵
stderr	nothing sent to stderr

 

Example 9
transformtxt -s 0 -t 3 sample.txt
input sample.txt	—-*↵ —**↵ –***↵ -****↵
stdout	—↵ –*↵
stderr	nothing sent to stderr

 

 

 

Example 10
transformtxt -x -r Hello HELLO sample.txt
input sample.txt	Hello, World. Hello, Minecraft.↵ ↵ ↵ hello, Nintendo. Hello, Steam.↵
stdout	HELLO, World. Hello, Minecraft.↵ hello, Nintendo. HELLO, Steam.↵
stderr	nothing sent to stderr

Example 11
transformtxt -s 0 -x -g -r day o -w leading sample.txt
input sample.txt	Today is tomorrow.↵ Yesterday is today.↵ Twesday is not real.↵
stdout	Too is tomorrow.↵ Tweso is not real.↵
stderr	nothing sent to stderr

 

Deliverables Summary

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.

Deliverable 1

Provided

• transformtxt specification (linked in this document above)
• Skeleton of the main class for transformtxt (linked below)
• JUnit 5 example tests and skeleton of test class to submit (linked below)
• JUnit 5 library (linked below)

Expected

• Part I (Category partition)
  • txt: TSL file you created
  • txt.tsl: test specifications generated by the TSLgenerator tool when run on your TSL file
• Part II (JUnit tests)
  • java: JUnit tests derived from your category partition test frames

Deliverable 2

Provided: TBD

Expected: TBD

Deliverable 3

Provided: TBD

Expected: TBD

Instructions

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

Part I

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.

Tools and Useful Files

TSLChecker (Optional, but recommended)

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:

• Windows: tslchecker-windows-latest.zip
• macOS: tslchecker-macos-latest.zip
• Linux: tslchecker-linux-latest.zip

TSLgenerator

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:

• 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 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.

Committing Part I

1. Create a directory “IndividualProject” in the personal GitHub repo we assigned to you.
2. Add the following two text files to this new directory:
   1. txt: TSL file you created.
   2. txt.tsl: 50 to 90 (inclusive) test-case specifications generated by the TSLgenerator tool when it processes your TSL file.
3. Commit and push your files to GitHub.

 

Part II

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:

1. Download archive individualproject-d1.tar.gz
2. Unpack the archive in the directory “IndividualProject”, which you created in Part I of the deliverable. Hereafter, we will refer to this directory as <dir>. After unpacking, you should see the following structure:
   1. <dir>/transformtxt/src/edu/gatech/seclass/transformtxt/Main.java

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.

1. <dir>/transformtxt/test/edu/gatech/seclass/transformtxt/MainTest.java

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.

1. <dir>/transformtxt/test/edu/gatech/seclass/transformtxt/MyMainTest.java

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

1. <dir>/transformtxt/test/edu/gatech/seclass/transformtxt/OutputCapture.java

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.

1. <dir>/transformtxt/lib/junit-platform-console-standalone-1.9.1.jar

JUnit 5 library to be used for the assignment.

3. Use the test frames from Part I to generate additional JUnit test cases for the transformtxt utility, one per frame, and put them in the test class MyMainTest. For ease of test design, it’s recommended that you name your test cases transformtxtTest1, transformtxtTest2, and so on. It’s required that each test contains a concise comment that indicates which test frame the test case implements. It should at least have the following comment format:

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

Designing your tests

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.

 

Committing Part II and submitting the deliverable

1. As usual, commit and push your code to your individual, assigned private repository.
2. Make sure that all Java files are committed and pushed, including the ones we provided.
3. Make sure to also commit and push the provided libraries (lib directory). To do so, you may need to force add the jar files (i.e., “git add -f lib/*”), since they are typically excluded by the “.gitignore” file.
4. Check that you committed and pushed all the files you needed by doing the following:
   1. Clone a fresh copy of your personal repo in another directory.
   2. Go to directory IndividualProject/transformtxt in this fresh clone.
   3. Compile your code. One way to do this is to run, from a Unix-like shell^[2]:

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

1. Run your tests. Again, from a Unix-like shell, you can run:

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

5. Submit on Gradescope a file called txt that contains, in two separate lines, (1) your GT username and (2) the commit ID for your submission. For example, the contents of submission.txt for George P. Burdell could look something like the following:

submission.txt

gpburdell1

81b2f59

 

 

 

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:

• a positive response from Gradescope only indicates that you passed the initial checks and is meant to prevent a number of trivial errors;
• if your submission does not pass the Gradescope checks, it will receive a 0, so please make sure to pay attention to the feedback you receive when you submit and keep in mind that you can resubmit as many times as you want before the deadline. Once the assignment closes, we will not be able to regrade assignments that fail these Gradescope checks.

Gradescope Queries

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.

 

FAQ

1. What’s in Deliverable 2? What is the workload like?

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.

2. Can I create additional tests not generated by TSL or avoid implementing some of the generated test frames?

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

3. Aside from the program options and parameters, should the file be considered as a separate category partition?

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

4. Should I test the size limits/capabilities of strings, input files, and others?

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.

5. Is it okay that most of my tests are failing locally?

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

6. Can I re-use the example test cases (input strings, arguments, etc.) or test methods for my own test cases?

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.