Skip to content

Latest commit

 

History

History
95 lines (57 loc) · 3.38 KB

README.md

File metadata and controls

95 lines (57 loc) · 3.38 KB

Stateless unit testing using examples, tables, and properties

In this project, we'll use jqwik for practicing these styles of unit testing.

Individual project

  • Discuss your approach with your classmates, TA, and instructor
  • Maintain and submit your own repository

Project description

Fix the various TODO items until all tests pass, including those you are about to add.

❯ grep -r TODO src

Nonfunctional requirements

For full credit, the various palindrome checkers should meet the following nonfunctional requirements (NFRs):

  • constant additional space (O(1)) preferred
  • up to arg.length / 2 additional space acceptable
  • as DRY (don't repeat yourself) as possible, i.e., the methods should call each other as appropriate

In addition, the project must meet these NFRs:

  • multiple git commits
  • unchanged Maven-based project structure and dependencies (you may add additional useful dependencies)
  • compiles and runs (main and tests) using mvn

Running the main program

The main program checks whether the command-line arguments form a palindrome, defined as a string that reads the same way forward and backward, possibly considering or ignoring case and/or spaces. When inspecting the main method, you'll see that it concatenates the command-line arguments to a single string with spaces in between.

❯ mvn compile exec:java -Dexec.args="Rad a r"
checking Rad a r
Rad a r is not a palindrome.
Rad a r is not a case-sensitive palindrome.
Rad a r is a case-insensitive palindrome when ignoring spaces.

Running the tests

You can run all the tests

❯ mvn test

or a specific test or single test method, which is recommended while you're focusing on each specific part of the project

❯ mvn test -Dtest=TestPalindromeExamples

❯ mvn test -Dtest=TestPalindromeExamples#testRadar

You can generate the coverage report using

❯ mvn jacoco:report

Written part

Succinctly answer the following questions in a separate document called Answer.md in this repository.

  • Which of the NFRs listed above are dynamic or static, respectively?
  • Why is space performance important for a predicate like isPalindrome?
  • To what extent does the result of invoking one of these predicates depend on prior invocations?
  • Accordingly, what would be a relatively straightforward way to improve their performance?
  • What is an advantage of data-driven testing over example-based testing?
  • What is an advantage of property-based testing over example-based and data-driven testing?
  • Briefly discuss the pros and cons of a generate-and-check-based property as compared to a property based on a generator that generates test data more directly, such as the ones listed below under extra credit?

Grading

  • 2 NFRs
  • 1.5 three palindrome checker methods
  • 0.5 invoke additional two checkers in main
  • 1.5 additional example-based tests
  • 1.5 additional tables for data-driven tests
  • 1 additional properties
  • 2 written part
  • 10 TOTAL

Extra credit

  • 0.2 add a working CI status badge for your project
  • 0.5 for an efficient generator of case-sensitive palindromes up to a given length
  • 0.5 for an efficient generator of case-insensitive palindromes up to a given length
  • 0.5 for an efficient generator of case/space-insensitive palindromes up to a given length
  • 0.5 for an efficient generator of non-palindromes up to a given length (easiest)