Note for EECS 368 with Professor Alexander at KU
Note for EECS 368 with Professor Alexander at KU
Popular in Course
Popular in Department
This 2 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at Kansas taught by a professor in Fall. Since its upload, it has received 31 views.
Reviews for Note for EECS 368 with Professor Alexander at KU
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 02/06/15
Test Methods Test Classes EECS 368 Programming Language Paradigms Fall Semester 2002 Handout 1 Some Thoughts on Testing s was pointed out in class the first homework assignment does not define a main method that starts and runs a defined program The reason for this is that you are defining a collection of utilities not a stand alone program The vast majority of code that most of you write in your careers will be in the form of support code or utilities that don t necessarily have main programs The fact that no main method has been defined does not imply that you don t need to execute your code On the contrary it is vital that you test all your code to debug and eventually demonstrate correctness This is part of all code development processes and as a part of this course you will start thinking about how to test your code One mechanism for structuring your tests is to add a test method to each of your major classes The test method should probably be a class method but you may have good reasons for making it an instance method When called the test method should evaluate each function associated with the class and use print statements to report results Try not to read anything from files or other input sources You can use parameters to facilitate testing if you need to pass information into the test method To invoke your test methods include a class that provides a main method that calls test methods from other classes Something like the following class testClass lt Test Variable Declaration and Initializationgt public void mainString args ltLoca Test Variable Declaration and Initializationgt class testO cla552testvi v2 The body of the main method calls test methods associated with the classes you would like to test If your test methods are instance methods it will be necessary for you to create instances of classes you would like to test Your calls to test methods may be far more involved that this but this template should serve as a good starting point Even if you don t define test methods for your classes you can use the main method in your testCass to create objects and run test routines This is somewhat less elegant than defining test methods but can be equally effective It also works for languages like scheme or ML that don t directly provide support for object oriented programming With the testCass defined you can now compile the class and execute the main EECS 368 Test Cases Programming Language Paradigms method to run tests on your class definitions When your work is being evaluated the tester or grader in our case can immediately go to the testCass invoke main and see exactly what your code does When you make changes to your code you can easily run your test methods again to make sure that you didn t accidentally introduce new bugs If you are worried about code and executable size there are ways to pull your test methods and classes out of your source before you compile deliverable code For our class this is not necessary or even advisable Your testing process is only as good as the test cases that you choose In your Software Engineering course you will learn several techniques for choosing test cases Here are a few random thoughts on how I go about choosing test cases 1 Cover Boundary Cases When testing integers or reals always look at the 0 case or cases that represent the extreme limits of input ranges For lists arrays and other containers test the empty case and the full case should it exist Always look at the edges of your data structures 2 Cover conditional statements Test cases should make sure that both then and else cases are covered for if statements entry and exit cases for while do while and for loops and various cases for switch statements 3 Try to overrun structures Try to generate tests that overrun arrays and lists See what happens when structures get full and stressed This will find performance issues as well as errors in your code 4 Try to break your code A test that has no potential to find an error is useless No amount of testing will prove a program correct but failed tests will show that there are errors Always try to break your code 5 Documentyour test cases It sounds odd but explain why you have chosen your test cases You don t need very many words just a quick note indicating why the case was chosen
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'