1.a) Examine your final test suite and perform Input Partitioning (also see cookbook for an example) and describe the following:

• The result of your input partitioning: What equivalence classes does your test suite contain? List at least 4, and provide a link to an example test case in your test suite that is in each.
• Reflect: Are the amount of input partitions that you have more, less, or about the same as you expected? Why do you think this? Does your test suite contain any redundant tests (that occupy the same input partition)? If so, provide two example test cases from your suite that are redundant. and reflect--why did you add the redundant test? If it did not have redundant tests, why not?

7 equivalence classes, for addDataset:

• Not identical to an ID of a dataset that has already been added
• Empty string
• String with only whitespace
• String with underscores
• Duplicate ID (same as already added dataset)
• Missing course folder
• Empty course folder

I have more input partitions that I expected, especially for querying; I think this because I realize that if I had gone through through the test scenarios more systematically, I would have less overlap with my test cases. Two test cases that occupy the same partition is the test that checks for an invalid ID for removeDataset, and one that checks to see if an ID with only whitespace is invalid. I added it because although have the same functionality and final result, I thought that isolating it to whitespace would be useful. I now realize that this may be redundant.

1.b) Considering your final test suite and your input partition analysis above, did you perform output partitioning? If so, in what ways did output partitioning strengthen your test suite compared to what you captured in 1a?

I performed output partitioning by checking the reference UI for different insight errors, and looking at those errors to determine if I had encountered all possible exceptions and issues, instead of just taking a look at differing inputs. I think it strengthened my test suite because it allowed me to catch bugs in my code, such as me not passing through exceptions for my checkQuery. It also made me realize that a lot of my tests were checking the same insight errors and having the same results, causing me to re-evaluate them and see if they were really necessary.

1.c) How well did your process of test generation go? What techniques did you use and how effective did you think they were in producing a quality test suite? What would you change for the next time you need to create a suite of tests, and what would you keep the same?

My process of test generation worked, although I felt like I spent more time then was actually necessary in order to have a well-tested suite, because I didn’t go through it systematically. My technique was just thinking of different inputs and trying them out, without first drawing out a tree of the inputs and branching them into varying levels of difference. Since I didn’t do this, once the number of tests became larger I had a harder time recalling what was already tested and what wasn’t, making me waste time determining what parts of the code hadn’t been tested yet. The next time I need to create a suite of tests, I’ll first draw out a tree of an initial case, then look at the inputs and outputs and begin branching out the initial one into various options, and branching off of those. I would keep the compartmentalization I had the same, where I have the invalid and valid tests in the same area of the code.

1.d) How many more (if any) tests do you think you will add by the end of the next project phase (c1)?