This chapter is from the book
This chapter is from the book
This chapter is from the book
Testing
You must test your solution thoroughly before submitting it for grading. Most candidates use a Windows development environment. That is fine. However, the solution must also work on Unix and especially Solaris. Theoretically, it should work without any worry on your part. However, Java isn't perfect, and neither are you, so there are a few things to check before uploading. For example, your solution has to open the database binary file, so make sure you have implemented an OS-independent way to do that. Also, the user help file has to be opened. If you bundle the HTML help file in the submitted JAR file, as opposed to just pointing to an online URL, your solution has to get to the file in an OS-independent fashion.
TIP
If you instruct the evaluator to use start scripts (included in the README.TXT file) for running your solution, be sure to have start scripts for both Unix and Windows.
To ensure that your solution is portable, one necessary test is testing the client and server on both Windows and Unix in various combinations. The following are the recommended tests to make sure your solution works well on either OS and in mixed environments, in which one part is on one OS and another part is on another OS. You can easily adapt this test suite to include another OS, such as Macintosh or another Unix variant. The following are the test scenarios you should consider (order is not important):
Client (local mode) on one Solaris box.
Client (remote mode) and server on the same Solaris box.
Client (remote mode) on one Solaris box while the server is on another Solaris box.
Client (remote mode) on one Windows box while the server is on another Windows box.
Client (local mode) on one Windows box.
Client (remote mode) and server on the same Windows box.
Client (remote mode) on a Windows box while the server is on a Solaris box.
Client (remote mode) on a Solaris box while the server is on a Windows box.
CAUTION
Neglecting to thoroughly test your solution for all possible click and keystroke combinations is foolhardy. Also, be sure to test on both Solaris and Windows with the client and server on one OS and then test with the client and server on different OSs.
Cygwin
Those developers who use a Windows development environment (the majority of candidates) often have difficulty finding a Solaris box to test their solution. I was fortunate to have several Solaris servers at work, so I tested my solution carefully on them. My tests uncovered a few problems that were not evident on Windows. For example, I discovered that part of my file pathing worked fine in both Windows and Unix, but another part did not because I used a Windows-specific path separator. In one mode, this separator wasn't used, but in another mode it was—and it failed gloriously on Unix. After fixing that, I found a major bug not in my code, but in RMI. That problem would have failed my submission had I not found it.
If you don't have access to a Solaris server, there are options. You can download Solaris or another Unix flavor, and install it temporarily on an extra box for testing. Likewise, you might install Linux. You can even dual-boot for a while. Another interesting way to test your solution on Unix is to use Cygwin (http://www.cygwin.com), an excellent Unix emulator for Windows.
Cygwin consists of a dynamic link library (DLL; cygwin1.dll) that acts as a Unix emulation layer. This emulation layer provides considerable Unix API functionality. Cygwin also comes with a large collection of tools that provide the Unix/Linux look and feel. When I tested my solution on Solaris, I also tested it with Cygwin (1.3 on Windows 2000), using the same seven combinations listed previously. Cygwin is free because it is composed of GNU software, pieces under the standard X11 license, and parts in public domain; Red Hat placed its contribution under the General Public License (GPL).
Figure 18.1 shows what it looks like to run a Java program from Cygwin.
)
Figure
18.1 Running the solution server in Cygwin.
It is worth the effort to try your solution in Unix, whether it is a Unix or Solaris box. If you don't have access to a genuine Unix box, get Cygwin and try it in that.
JUnit
Quality control is a key function in any software development methodology. Although the certification assignment isn't large, it still requires the entire life cycle you find in large projects. Testing is as mandatory for your certification project as it is for commercial projects.
NOTE
The JUnit and Ant tools are free and open source. You can download them from the URLs in "Need to Know More?" at the end of this chapter.
One way to improve your testing is to use a testing suite, such as JUnit (http://www.junit.org), which enables you to write repeatable tests. Using a unit-testing framework like JUnit simply adds a measure of certainty about your final submission. You won't need to guess whether your application meets all the assignment requirements. Because testing is not a core part of development, most programmers skip it. After all, a dedicated quality assurance (QA) tester or even an entire team is usually responsible for testing, so why should the developer take precious time to write testing code? Using JUnit can help you measure your progress.
QA departments are mostly interested in integration testing—seeing whether components work well together. Integration testing is mandatory before submitting your project. However, first you should conduct unit testing, which is testing each single unit of code individually. One way to approach unit testing is to focus on a single class. This approach narrowly defines what is being asked of your code. JUnit will definitely help you create a test that is fully automated and binary. That way, you will know whether your class succeeds or fails.
To avoid uploading hidden bugs or unintended side effects, use JUnit, which comes with a graphical interface to run tests. You do not have to create numerous and elaborate tests. However, a few key tests will help you. For example, write a test class for the database and RMI portions of the application. You can then run the test in JUnit, which shows its progress with a progress bar for visual feedback. JUnit reports passing tests with a green bar and displays a red bar when there is trouble. JUnit also displays failed tests in a list at the bottom of the GUI.
Test Plan
If you take the time to write a quick test plan, you will save time overall. You might want to adapt your test plan from the IEEE standard 1008-1987, "Standard for Software Unit Testing." (Testing documentation and the testing process are described in Appendix B, "Documentation Standards.")
In my project submission, I mentioned part of my test process because I thought thoroughly testing the application would impress the evaluator. Also, if the evaluator found a major problem, he or she would know it wasn't caused by gross neglect (causing an automatic failure), but merely a simple mistake (meaning the worst-case scenario would be losing some points).