Paul, let's standardize the structure of the test cases now before we get in too deep.
The way that the harness is setup right now is that you use TestCaseTemplate.py as a template for your test case. Then, just copy it into the directory, import it in the module init file, and be sure to add the suite to the suiteList. Does this seem easy enough? For the Test Case names, I think we should stick with the regular dabo convention and go with testNameOfTest instead of the test_NameOfTest. unittest only requires that "test" be in the front of all test cases. Same deal for File and Class names. I noticed in test_dConnection.py that you had empty setup and teardown methods. They are hook methods and if you don't need to put anything in them you don't need to define them in the test class. I do think that we need to define a docstring for each test method in each class. Just a simple one liner will do. This is because unittest will display the docstring in the output instead of something like "testchoice (__main__.TestSequenceFunctions) ... ok". It's a lot handier and easier to read. Ok, that's all the easy stuff. Now the harder stuff is defining the break up of test classes. ---------------------------------- Were to start. I like the idea that one real class has all of it's tests in one file. However, I am not so keen on having them all in one class. Makes it incredibly hard to read. Take your bizobject test file for example. It is almost 400 lines long already and most of that is a single class. A lot of tests are missing. Some of the test methods like test_RowCount and test_RowNumber are really several tests in one. Let's take a Property for instance. It has getter and setter methods that we want to do test. Testing known values is one test. A sanity check test in which result = get(set(result)) is another. If the property has a limited input range there could be several tests that check if the function fails with bad input. With each test case answering a single question about the code our number of test cases will be in the thousands. Daunting task isn't it.... So, let's go back to the class organization. I have 2 schemes that I can think of. 1) If we want to test the RowCount property, we can have a testRowCount class. Each method and property can have there own test class. Coupled functions that are reciprocals can and probably should share the same test class. If you need a standard setup for all test classes, have a base class that overrides the setUp and tearDown methods. 2) Define test classes by category. For example, the testBizobjBadInput class would run all of the tests for bad input in the class. You could have testBizobjKnownValues, testBizobjSanityChecks, etc. and just define custom classes for anything that doesn't fit a standard value. Regardless we have to break up these humongous test classes. With it being common to have 5-10 tests per class function, these test files will quickly spiral out of control in a framework this big. I personally like a scheme like number 2 but if you have a better way. For an example that will explain this better than I ever will, go to http://www.diveintopython.org/unit_testing/index.html#roman.requirements and look at the test class structure for just 2 functions. Notice how there are multiple classes testing the same object. That's what I am talking about. ------------------------------------ I have another issue with the way you dealt within the dCursorMixin testing. Every piece of code should be tested only once. We write a set of test classes for the mixin code and bam, we don't need to test the mixin code for every UI object. In the tests right now, that dCursor mixin code is run 3 times......I see why you did it because you needed the database backends for the code to work right. However, we will set up a mock database object for that. This is all I can think of for now. Let's nail this thing soon so the conversions can start. And if you really want to know more about unit testing and how to use the unittest module, go to http://www.diveintopython.org/unit_testing/index.html#roman.requirements and read the tutorial. Cheers, Nate L. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
