Requirement
This request assesses your basic knowledge of Java and JUnit, which you will need for future requests and projects.
Instructions
To complete the request, you must complete the following tasks:
Clone your individual GitHub repository in your local workspace. This is the same repository that you used for the previous request and will use for all future individual requests.
Download the archive request3.tar.gz
Extract the archive in the root directory of the repository, which will create a directory called request3 and several subdirectories. Hereafter, we will refer to the directory request3 in your local repo as dir . (If you do not know how to extract a “tar.gz” archive, you should be able to find plenty of resources on how to do that online–ask on Piazza otherwise.)
Directory src contains, in a suitable directory, Java interface MyCustomStringInterface . It also contains an exception class MyIndexOutOfBoundsException , which is used by the interface.
Directory test contains, in a suitable directory, a template JUnit test class MyCustomStringTest .
dir/lib/junit-4.12.jar and dir/lib/hamcrest-core-1.3.jar, JUnit and Hamcrest libraries to be used for the request.
Your first task is to develop a Java class called MyCustomString that suitably implements the MyCustomStringInterface interface that we provided. (The semantics of the methods in the interface should be obvious from their name, the JavaDoc comments in the code, and the test examples in class MyCustomStringTest–ask on Piazza otherwise.) Class MyCustomString should be in the same package as the interface and should also be saved under [dir]/src/edu/seclass .
Your second task is to develop a set of JUnit 4 test cases for class MyCustomString by completing the provided template test class MyCustomStringTest , which contains 3 complete test cases and 13 to-be-completed test cases. For each test case in class MyCustomStringTest whose body simply consists of the placeholder “ fail(“Not yet implemented”); “, you must do the following:
Replace the placeholder instruction with a meaningful test case for the corresponding method , which is indicated in the comments and name of the test.
Replace the text “ [Add test description here] “ in the test comment with a concise description of the purpose of the test (e.g., “Count strings in an empty string”) without modifying anything else in the comment and making sure that your comment consists of a single line (i.e., does not contain newlines) and does not contain quotes or other special characters.
Make sure that every test method has a suitable oracle (i.e., either an assertion or an expected exception) and that the tests are not trivial (i.e., are not a copy of the provided one and have a specific purpose). In other words, each test should (1) test a specific piece of the functionality, and (2) check that such a piece of functionality behaves as expected.
It should be obvious, but please also make sure that all the test cases you created pass when run against your code.
In addition, at least two of the tests that you develop must result in an expected exception (e.g., NullPointerException ). When testing for an expected exception, make sure to use the “ @Test(expected =
Submission
To submit your solution, you should:
Commit dir and push it to the individual remote GitHub repository we assigned to you . Make sure not to push your work to any other repo, especially public ones. In the best case, you may end up submitting a commit ID we cannot find. In the worst case, you may be violating the honor code.
Make also sure to 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/* “), which are typically excluded by the “ .gitignore “ file.
Submit on gradescope a file, called submission.txt that contains, in two separate lines (1) your GT username and (2) the commit ID for your submission. For example, the content of file submission .txt for George P. Burdell could look something like the following: submission.txt
As soon as you submit, your request will be graded by compiling your code and running it against both your test cases and a set of test cases, written by the instructors. All tests must pass. 1 After that, which should take a few minutes at most, you will see a report with your grade and some corresponding feedback. The feedback should be self-explanatory (e.g., “ERROR: You have 16 tests instead of 15.”), but please let us know otherwise.
The grade you will see on gradescope is your actual grade for the request , unless we find some issues with your submission (e.g., hardcoding of the results, identical tests, or similar).
You can resubmit as many times as you want before the deadline , so you have a chance to address issues with your requests if gradescope finds an issue with your submission.
Notes
Make sure to submit only the test cases in the template and do not add extra tests. If you feel compelled to add additional tests, feel free to do so in a separate test file, which you can add to your repo but won’t be graded.
Do not use any external library other than the provided JUnit 4 and the associated
Hamcrest library. You can obviously use all the standard JDK libraries, 2 and you really should not need any external one.
You cannot modify any of the following:
The provided interface ( MyCustomStringInterface )
The already provided test cases (except for those that you are supposed to implement, obviously, whose body is simply “ fail(“Not yet implemented”) “).
The test class name, the names of the test cases, and the test comments, except for replacing “ [Add test description here] “ with a concise description of the purpose of the test. (We understand that it may be advisable to use more meaningful names for the tests, but having numbered tests helps the grading.)
The declaration of mycustomstring in the test class.
You should use Java version 11 or 12 to solve the request.
Before submitting, make sure to compile and run your test cases as a group (not only individually) and to check that they all pass. Although gradescope performs the same checks, it is much faster to do that locally, on your machine, beforehand.
Verify that your final commit ID contains what you intend, and is pushed to the repository, by cloning it in a separate location or viewing it on github.
More specifically, you can check that you committed and pushed all the files you needed by doing the following:
Clone a fresh copy of your personal repo in another directory
Go to directory request3 in this fresh clone
Compile your code.
Run your tests. Again, from a Unix-like shell
You can perform multiple commits as you produce your solution. This is not only fine, but actually very much encouraged.
We also encourage you to use a “development” branch and merge your stable version(s) into the “master” branch. If interested, see this site for an example of a possible branching model of this kind. (There are many others.)
From this point on in the course, you should NOT run the git repository reset commands given in request 2, any version of force –push , or any commands deleting branches, tags, or prior commits on your repository, as these commands could cause you to lose prior work.