General discussion

Locked

Unit testing

By dinesh_sardar ·
What are the strategies for Unit testing ??
Which is the Best.

This conversation is currently closed to new comments.

11 total posts (Page 1 of 2)   01 | 02   Next
| Thread display: Collapse - | Expand +

All Comments

Collapse -

Unit testing

by RealGem In reply to Unit testing

Some strategies include:
- black box testing
- complete testing
- using test cases

Black box testing assumes you know nothing about how the component is supposed to work. You test it "blindly".

Complete, exhaustive testing, on the otherhand, requires you to test every possible code pathway.

Test cases, assuming that they are based on requirements, allows you to ensure that the component does what the user needs it to do.

Note that these strategies can be combined; they are not necessarily mutually exclusive.

The BEST solution depends on how you feel about these tradeoffs:
- black box testing may not catch all the errors, but it is easier than complete testing
- exhaustive testing is very thorough, but is very expensive and time consuming
- test cases are more work than seat-of-the-pants testing, but the quality of the result is higher

Collapse -

Unit testing

by dinesh_sardar In reply to Unit testing

The question was auto-closed by TechRepublic

Collapse -

Unit testing

by leif In reply to Unit testing

Since you called it "unit testing" and this forum is mostly software, I assume you're trying to test a chunk of a program to see if it works as expected. "Functional test" is more often used to describe testing to see if a complete program meets requirements.

As a programmer, I usually write a unit test for each compilable module (Java class, C file, C++ class, etc.) that I'll deliver. These are "glass box" tests, because I have full access to the code, and can look at the internals to be sure I've tested what I want to. I also sometimes write "black box" tests for libraries, in which I make sure that a behavior I am counting on is actually the case.

The tests fit into a test harness that can run all the unit tests and report success or failure(s); this way, I can make changes and have some confidence that they haven't broken another module. It's important that the tests be easy to run and easy to interpret.

As a minimum, each unit test should ensure the module's externally visible interface (e.g., Java 'public', package-scope, and 'protected' methods) produce correct results for a variety of inputs, including erroneous inputs when possible.

For better testing, I like to make sure the test exercises all lines of code. In an IDE, this is easy: set a breakpoint on every line of code, and run the test. Every time a breakpoint is triggered, clear it. At the end of the run, remaining breakpoints mean that your test didn't execute the line. For better coverage,make sure that all compound conditionals are executed with each simple conditional evaluating to true and also to false.

Note, however, that this is neither complete nor exhaustive testing. Cem Kaner (http://www.kaner.com/imposs.htm) has a lot to say about this.

Collapse -

Unit testing

by dinesh_sardar In reply to Unit testing

The question was auto-closed by TechRepublic

Collapse -

Unit testing

by KoolKos In reply to Unit testing

This is actually a partial reprint of information that was e-mailed to me from the Quality Technologies Newsletter and is relevant to your question ? I really cannot legitimately take credit for the piece but still felt I should pass it on. -KoolKos

--begin part 1 of 3--

Unit Testing by Michael Reidy (MREIDY@aol.com)

Unit testing of new software is an initial step in the testing cycle. It is conducted by the coder, to determine if newly created software adequately meets stated requirements. A few limited transactions are input to exercise the code. Upon satisfactory completion, the code is handed off for additional, more rigorous testing by the Quality professionals (regression testing, systems testing, integration testing, etc). As a first link in the chain, it is essential. But even more importantly, it is the cornerstone for subsequent system development. As the subsequent testing occurs, so too does additional coding. A thorough Unit Test identifies deficiencies, providing smooth testing and coding processes.

--end part 1 of 3--

Collapse -

Unit testing

by dinesh_sardar In reply to Unit testing

The question was auto-closed by TechRepublic

Collapse -

Unit testing

by KoolKos In reply to Unit testing

--begin part 2 of 3

RECOMMENDATIONS

(1) Familiarize yourself with existing procedures and templates. There may well be existing templates at the customer site. If not, design your own. Be sure to include:

- Test scenario; - Description of error; - Date found; - Reference (tie in with bug tracking mechanism); - Status; - Person responsible (if not captured on separate bug tracking mechanism).

Remember, you want to keep this as concise and easy to complete, as possible. One last note,as part of this research, be sure to look at the original Statement of Work. You might see mention of a customer's unique requirements that impact Unit Testing.

(2) Elicit comments from coding staff. There may well be a sound reason why formal procedures aren't being followed. Additionally, the coders may offer some good suggestions on conducting and documenting the Unit Test. Getting their input also gets them "on your side".

(3) Identify any improvement needs and design the template andprocedure you need. Completion should require the least time possible. (As an aside, excessive time is the probable reason for not following sound procedures). Try to eliminate as much data entry as possible. Boiler plate required input. Rely on soft copy where possible. Remember, you need to design the procedure that minimizes effort but maximizes effectiveness. Along this line, you should also consider providing data beyond the Quality staff. Email, posting to a corporate intranet, regularly scheduled reviews should all be considered.

--end part 2 of 3--

Collapse -

Unit testing

by dinesh_sardar In reply to Unit testing

The question was auto-closed by TechRepublic

Collapse -

Unit testing

by KoolKos In reply to Unit testing

--begin part 3 of 3

(4) Consider a policy of requiring dual signatures (the coder and manager, both). This will ensure added thoroughness and accuracy.

(5) Discuss the importance of Unit Testing with coding staff management. Make them aware ofyour concerns. Offer to conduct brief tutorials/training sessions for their staff. You need to sell them on your procedure and how it will benefit them (reduce staff effort and rework).

(6) Once established, maintain a strict policy of requiring thorough Unit testing. Don't accept software without the needed signoff/documentation. The first time you allow an exception, the rule is lost.

CONCLUSION

The key to Unit testing is establishing and maintaining a smooth hand-off from the coderto QA. Remember, you and your customer will benefit as testing becomes more timely, more thorough and more accurate.
----

--end part 3 of 3--

Collapse -

Unit testing

by dinesh_sardar In reply to Unit testing

The question was auto-closed by TechRepublic

Back to Web Development Forum
11 total posts (Page 1 of 2)   01 | 02   Next

Related Discussions

Related Forums