Software Testing

Unit testing represents breaking code into functional components, then writing test scripts that test the code.  For example, if I wrote a function called ReverseString() I would then write a unit test that passes different strings into the function and compares the result to the expected result.

Unit testing has it's strengths, however, it takes time to develop the scripts and if the programmer that wrote the code, writes the scripts then he/she could miss things.

Also, unit testing works best for discrete functions (like reversing a string) where this is clearly defined entrance, exit point.   The word 'Unit' is key to understanding what it's intent is.  It's not 'System' testing.  It is for units of code.

I generally use it for core code that will extensively reused.

There is no substitute for having a trained QA person design test scripts and ensure that systems work as designed.

If your code is in production this is trial by fire.  What you can do to test it is compare the "what it is supposed to do" with "what it actually does".  Find out from users if it is doing what they want it to do.  You may be able to send it some test input but only if this can be done safely.  You will not want to interfere with business critical processes.  In realtime systems you may be able to observe the goings on with an in circuit emulator.  You may be able to examine network traffic with a sniffer.  You can use a spy too look into objects.  But basically, all testing goes back to my second sentence.

You conduct unit testing by performing the steps identified by the unit test and comparing the expected results with the actual results. If they do not match, the code fails unit testing.  Code that does not pass unit testing does not go into production, in a perfect world.

I recommend investing heavily in analysis upfront.  Then do a high level architectural model of what your system is going to do.  Then design a solution on how it is going to do it.  Then, before writing any code whatsoever, I recommend creating your users manual and system documentation. Define your databases, inputs, and outputs.  Once that is done, you can write code.  As details are uncovered, you will always be going back through the prior stages.  Always, no matter what, keep your users and system documentation current!  I also recommend doing code walks after units of code are written.   I also recommend creating test plans both system and unit that verify your completed code work according to the specifications manual in your users manual.

There is no substitute for knowing what you want/need your system to do.

Here are some links to some well thought out testing strategies:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dgcd_tst_pkyl.mspx?mfr=true
http://www.w3.org/TR/2002/WD-qaframe-test-20021220/
http://www.ambysoft.com/essays/floot.html

For unit testing you'll want to use one of the capable "xunit" frameworks -- junit for java, nunit for .net languages like c#, pyunit for python, etc. These unit testing frameworks allow you to write code that exercises your classes through their public API and then check (i.e., "assert") that some condition is true or false afterwards. Unit testing typically tests one or a small group of classes in isolation.
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

As for a testing approach, I've been learning and practicing test-driven development for several years. In this approach you write the tests for some functionality prior to actually writing the code that implements it. TDD changes the way you think about the design of the public API of your classes and how you will verify through asserts that your code is doing what is expected. It encourages the application of object-oriented design principles, refactoring, and removal of duplication. You do enough analysis and design to be sure you understand the problem and have in mind a solution approach but you don't "invest heavily" in these activities. TDD advocates a more "agile" approach. Here's a series of links that might help you understand:
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
http://www.objectmentor.com/resources/publishedArticles.html
http://www.methodsandtools.com/archive/archive.php?id=4
http://www.agiledata.org/essays/tdd.html

One of the finest and most comprehensive testing references I have on my bookshelf is Robert Binder's book "Testing Object-Oriented Software". If you're really serious about testing, this is IMO the book to get.
http://www.bookpool.com/sm/0201809389

Beyond unit testing there is also integration testing, system testing, acceptance testing, performance testing, ... there are various tools, techniques, frameworks, etc., that may be applied. If you're interested in these areas there are lots of references on the web. Get ready to do a lot of reading.

Regards,
Jim Cakalic

How abt n unit, where can i learn and test using n unit?