Requirement
In our final exercise of the term, we’re going to be practicing writing UnitTests. The structure of the tests isn’t really as important as the testing plan, but we get to test both.
What to Test
We wanted to come up with a function for you to test that had a bit of everything: loops, selection, lists, strings, dictionaries, objects, etc. But we had a bit of a conundrum. We wanted something complicated enough to be interesting, but knew you were busy with your request, and didn’t want everyone to have to spend lots of time writing a new function in order to test it.
That’s when it hit us. You’re already writing a function that you’ll probably want to test anyway… cartesian product! It’s got everything we need, you already have to write it, and now it can help you test your own code for A2. (A pretty smart move if I do say so myself).
How to Start
Before you start writing any code, you should think about coverage testing, and how we came up with a test plan in lecture. Figure out all of the parameters, and the important ranges they fall into. Then write one test for each possible combination of ranges. The goal here is to find one example test case for all possible regions of your testing space.
Most of your actual tests will probably involve code that looks like this (now do you see why we made you write set dict and get dict?1
2
3
4
5
6
7
8
9
10d1 =
d2 =
t1 = Table()
t2 = Table()
t1.set_dict(d1)
t2.set_dict(d2)
result_table = squeal.cartesian_product(t1, t2)
result_dict = result_table.get_dict()
expected_dict =
self.assertEqual(result_dict, expected_dict)
What to Do
In a file called ex10.py, you should write a UnitTest to thoroughly test cartesian product. Your tests will actually be run on a version of the code that I have written. Therefore, you will be doing black box testing (you don’t know if I implemented the cartesian product or the Table class in the same way you will… in fact, you can bet that I probably won’t). My cartesian product function will be in a file called squeal.py, and my Table class will be in a file called database.py. Both will be placed into the same directory as your UnitTest. We’ve provided you with some starter code, just to make sure you can access everything correctly.
What to Submit
Submit your ex10.py file to MarkUs as usual. Your UnitTest methods do not need any DocStrings, and unless you’re doing something particularly unusual, you probably don’t need any internal comments either. However, your method names and error messages should be descriptive enough to properly explain what each test case does and why it’s useful. Remember that writing frivolous test cases is no better than missing useful ones.