Methods to improve quality of software projects, semester 6, spring 2006

New: planning for the assessment

Planning for the assessment in june 2006

What you can find here:

• Module blue print
• Sheets and handout of week2.
• Sheets and handouts on CVS usage.
• Sheets and handout of week3.
• Sheets and handout on regression testing with ant and coverage testing with Hansel.
• Sheets and handout on continuous building and testing with cruisecontrol. Also have a look at the build.xml ant file, the config.xml and the cc-build.xml wrapper.
• Sheets and handout on validation and the most difficult area in automatic testing: Validation and Gui testing. If also found a nice presentation on the internet on Selenium use. Have a look. It has some nice ideas.
• Karl Fogel's and Moshe Bahr's book on CVS
• A collection called CVS-Best Practices, also available in pdf format
• The plan, test and execute task.

Tasks

To hand in your tasks, you should the use peerweb upload facility. This works best for me, especially when I use linux, which I tend to do most of the time. There are some rules on how to package the stuff.

Week 1 and 2

Get acquainted with the junit test framework by executing the cookbook belonging to http://junit.org. Make sure to follow and study the links to the junit api.

Week 3

Implement and unit test the stack interface. Use a simple array to implement the storage inside the stack. See task description. Rationale: more aspects of junit testing can be shown that way. You find the stack interface definition at the resources page.

Week 4

Implement and test the ShoppingCart, defined in two interfaces, Item.java and ShoppingCart.java. The project, saved as cvs module is available in a zip as shop.zip on the resources page.

Week 5

1. Extend the shoppingcart with a salesopertunity functionality.
2. Add coverage test for all the classes and tests in this extended package.
3. Add or adapt a build script so the building testing and depoying can be done without an IDE.

There is a small problem with byte code engineering, certain compiler debugging settings and java5 with generics. The XXTestCoverage crashes with the wrong settings. My suspicion, which stems from interpreting the exception messages, is that it is a java5/bcel problem and not an eclipse or hansel problem. And also, with an ant build and debug set to true (not just lines), you get the same effect. If you set debug="lines" in ant, this problem is avoided as well.
For elipse the settings to compile/run the XXTestCoverage class can be found in this picture. Note that these settings apply to the code under test, not only to the XXTestCoverage class. So you have to do a project->clean if you want these settings to take effect.

Week 6-7

Have a look at Plan your (test) work.
To be able to give a reasonable estimate of the time you need for a certain amount of programming and testing work you simply need experience. In this case: pick up a programming job of which you estimate it will cost you approximately 8 real hours. That is 480 minutes and would fit in a week 21 times... Put this down in the plan and then execute it. Of course the code you develop must be fully unit tested including full coverage where doable. If there is any code (or prototype) for the sofa that you have to develop then that would be just right. Otherwise be inventive. A set of utility classes would be fine. A userinterface (particularly gui) is hard to test, so that would be harder plan to execute. Oh: one demand: use java.

Week 10-14

Test drive a Gui testing framework. Pick one that fits your SoFa.
Deliverable: a set of test scripts, an evaluation report and a presentation.

Week 15, from 6st of June 2006.

Assessment Metiq. The assessment concludes this subject. We plan the assessments well before the end of this semester. Each student will have a 20 minute talk with the tutor on his/her work. The student is expected to hand in the evidence of his work before the assessment. The method to hand in as well as the date will be published shortly.

Electronic handing in your work results

The peerweb facility allows you to hand in one document per type of task.

In the case you worked on the task with one or more partners, make sure all the partners hand in the stuff.

On every piece of code or documentation I want to see an author name+ student number. Multiple authors + student numbers are allowed.

There are several choices on what and how to hand in your stuff.

• Single file of type report. Upload the document in pdf format.
• Single source file. Simply upload the file. Not applicable for any of the currently defined tasks in MeTiQ.
• Program code. Hand in a zip file. The structure of the directory that you zip should contain your student number, so I can unpack all projects for all students in parallel, for instance for comparison. Before you pack the stuff, first remove all binary code (object files, java class files etc). In case you are using ant use the ant clean target.
• Program code with documentation. Put the documentation in a separacte directory next to the source code. For an example see below. In the example 2123456 is the student number of the student, whose file I am inspecting.

If you are using for instance eclipse with cvs, then a very fruitfull strategy is to check your stuff in with eclipse+cvs. Eclipse will leave out the unimportant files (and rebuild those on checkout). Then check it out with another cvs client (cvs on linux or mac, for instance tortoiseCVS on windows) in a properly named sandbox (named with your student number) like work/metiq/2123456/shop. Then zip that directory starting at the student number and name it for instance task2_2123456.zip.