Unit Testing

Unit Testing is a test that validates that the individual elements of the source code are working properly. A unit is the smallest testable peice of code of the application. The goal of Unit Testing is to isolate each part of the program and show that the individual parts are correct.
As soon as the programmer develops a unit of code, unit is tested for varous scenarios. As the application is built it is much more economical to find and eliminate the bugs early on. Hence unit testing is the most important of all the testing levels. As the software project progresses ahead, it becomes more and more costlier to find and fix the bugs. In most cases it is developer's responsibility to deliver the Unit-Tested code.
Unit Test Tasks and Steps :
1. Create a Test Plan.
2. Create Test cases and Test Data.
3. If applicable create scripts to run the test cases.
4. Once the code is ready execute the test cases.
5. Fix the bugs if any and retest the code.
6. Repeat the cycle until the unit is free of all the bugs.

Unit tests inspect both black boxes or white boxes.
Black Box Test
A black box test (also known as a "functional test") is one in which you feed it inputs and verify the outputs without being able to inspect the internal workings. Furthermore, one doesn't usually have information regarding:
1. how the box handles errors.
2. whether your inputs are executing all code pathways.
3. how to modify your inputs so that all code pathways are executed.
4 The dependencies on other resources.
Black box testing limits your ability to thoroughly test the code, primarily because the you don't know if you're testing all the code pathways. Typically, a black box test only verifies that good inputs result in good outputs (hence the term "functional test").
Classes are often implemented as black boxes, giving the "user" of the class access only to the public methods and properties that the implementer selected.

White box Test:
A white box provides the information necessary to test all the possible pathways. This includes not only correct inputs, but incorrect inputs, so that error handlers can be verified as well. This provides several advantages:
1. You know how the box handles errors
2. You can usually write tests that verify all code pathways
3. The unit test, being more complete, is a kind of documentation guideline that the implementer can use when actually writing the code in the box
4. Resource dependencies are known.
5. Internal workings can be inspected.
In the "write the test first" scenario, the ability to write complete tests is vital information to the person that ultimately implements the code, therefore a good white box unit test must ensure that, at least conceptually, all the different pathways are exercised.
Another benefit of white box testing is the ability for the unit test to inspect the internal state of the box after the test has been run. This can be useful to ensure that internal information is in the correct state, regardless of whether the output was correct. Even though classes are often implemented with many private methods and accessors. with C# and reflection, unit tests can be written which provide you the ability to invoke private methods and set/inspect private properties.

Code Coverage
Although there may be occasional exceptions, we need our tests to cover most of our code. 100% code coverage might be too high a goal to reach for right now, but we need to have a high percentage of the code we right covered in our testing.
There are a number of coverage criteria, the main ones being:
Function coverage - Has each function in the program been executed?
Statement coverage - Has each line of the source code been executed?
Decision coverage (also known as Branch coverage) - Has each control structure (such as an if statement) evaluated both to true and false?
Condition coverage - Has each boolean sub-expression evaluated both to true and false (this does not necessarily imply decision coverage)?
Modified Condition/Decision Coverage (MC/DC) - Has every condition in a decision taken on all possible outcomes at least once? Has each condition been shown to affect that decision outcome independently?
Path coverage - Has every possible route through a given part of the code been executed?
Entry/exit coverage - Has every possible call and return of the function been executed?

NCover is a useful tool for exploring how much of your code is covered by a single test or a suite of tests. It is an open source application, like NUnit.
The Visual Studio Team Test Edition also has a built-in code.

Unit Testing Patterns
Pass/Fail Patterns
The Simple-Test Pattern
The Code-Path Pattern
The Parameter-Range Pattern
Data Driven Test Patterns
The Simple-Test-Data Pattern
The Data-Transformation-Test Pattern
Data Transaction Patterns
The Simple-Data-I/O Pattern
The Constraint-Data Pattern
The Rollback Pattern
Collection Management Patterns
The Collection-Order Pattern
The Enumeration Pattern
The Collection-Constraint Pattern
The Collection-Indexing Pattern
The Performance-Test Pattern
Process Patterns
The Process-Sequence Pattern
The Process-State Pattern
The Process-Rule Pattern
Simulation Patterns
Mock-Object Pattern
The Service-Simulation Pattern
The Bit-Error-Simulation Pattern
The Component-Simulation Pattern
Multithreading Patterns
The Signalled Pattern
The Deadlock-Resolution Pattern
Stress-Test Patterns
The Bulk-Data-Stress-Test Pattern
The Resource-Stress-Test Pattern
The Loading-Test Pattern
Presentation Layer Patterns
The View-State Test Pattern
The Model-State Test Pattern


Code Smells
A code smell is a surface indication that usually corresponds to a deeper problem in the system.

Test Driven Development

Test-driven development (TDD) promotes the writing of tests prior to writing the code that is
being tested. This allows you to focus on your interface and what you expect from your code
prior to focusing on its particular implementation.
The testing components for implementing a test-driven development plan are known as unit
tests.
Test-driven software development technique requires that an automated unit test, defining requirements of the code, is written before each aspect of the code itself. These tests contain assertions that are either true or false.
In test-driven development, each feature begins with writing a test, so for each method, the developer should have to write a unit tests related case. Every method will have more than one test case depending on the complexity of the method signature.

Test-driven development gives developers the confidence to make changes to the system,
because they know that the tests will tell them if they have broken anything and where in the
application the break occurred. This is one of the most effective feedback mechanisms that
the development team can have for ensuring stability and high quality.

Another advantage to test-driven development is that it assists in keeping the code simple.
When developers take a code-first approach to development, they have a tendency to
design as they code, without having a clear picture as to what they want to achieve. They
basically let the creative process lead them to a design while they are coding. This often does
not result in the most straightforward solutions. In fact, in many cases, it results in an overly
complicated design. Test-driven development forces developers to think about the outcome of
what they are developing, and then simply code until the test passes, which leads to a simpler
design. This is called development by intention.

Best practices of using TDD:
1. Write the test first, then the code.
Reason: This ensures that you write testable code and that every line of code gets tests written for it.

2. Design classes using dependency injection.
Reason: You cannot mock or test what cannot be seen.

3. Separate UI code from its behavior using Model-View-Controller or Model-View-Presenter. 

Reason: Allows the business logic to be tested while the parts that can't be tested (the UI) is minimized.

4. Do not write static methods or classes.

Reason: Static methods are difficult or impossible to isolate and Rhino Mocks is unable to mock them.

5. Program off interfaces, not classes.
Reason: Interfaces can be easily mocked using Rhino Mocks and other mocking frameworks.
6. Isolate external dependencies. 

Reason: Unresolved external dependencies cannot be tested.


Test-Driven Development is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate the changes.
Requires test automation
"Keep It Simple, Stupid" (KISS [^]) principle
"You Ain't Gonna Need It" (YAGNI [^]) principle
"Fake it, till you make it" principle
Requires techniques, such as discussion and code reviews for example, to ensure not only that the correct features are implemented, but that the resulting code uses acceptable styles.

What are three Stages of TDD:

1. Red - Create a test case which is failing.

2. Green - Write minimal code to get the test pass.

3. Refactor - Improve the code to make it better but without changing the behavior. 

TDD Benefits:

1. Clear expectations (clear flow) of the code. 

2. Safety net for future changes

3. Supports continuous integration

Why TDD is more fit in Agile ?

Agile is an iterative development methodology where the term "Continous improvement" very well coined. Agile says that contnous improvement is the goal of the each iteration. 

Permission Denied - SQL Express 2005 Problem

I installed SQL Express 2005 on my Windows Vista PC and a SQL Server Express 2005 instance with the name GopinathMPC\SQLExpress is created successfully.

As a first step of using the new SQL Server Express 2005 I started creating a database with the query

CREATE DATABASE TestDB

GO

Unexpectedly execution of the above query failed with the following error message

Msg 262, Level 14, State 1, Server GOPINATHM-PC\SQLEXPRESS, Line 1
CREATE DATABASE permission denied in database 'master'.

The error message indicates that I don't have enough permissions to create the database. The login which I'm using to access my Windows Vista has administrative privileges, but still I'm not granted administrative privileges on the SQL Server instance.

Looking through the documentation of SQL Server Express, I found the that

Windows Vista users that are members of the Windows Administrators group are not automatically granted permission to connect to SQL Server, and they are not automatically granted administrative privileges.

Now it is very clear that event though I'm an administrator on my Windows Vista OS I don't have administrative rights on SQL Express 2005 Server. So I need to get administrative rights.

How to Grant Administrative Rights on SQL Express 2005?

1. Log in to Windows Vista using your administrative account
2. Open SQL Server Surface Area Configuration Application ( Start --> All Programs --> Microsoft SQL Server 2005 --> Configuration Tools -->SQL Server Surface Area Configuration)
3. Click on Add New Administrator (pointed in the image) link

1. A new window with title 'SQL Server User Provisioning on Vista' popup and displays the permissions on the left panel.
2. Select the permission 'Member of SQL Server SysAdmin role on SQLEXPRESS' available on the left panel and add it to the right panel with the help of add button( button with > text) available in the window.

1. Click on OK button to save the changes.
2. That's all now your Windows login has administrative privileges on SQL Server.

HAPPY DATA-BASING

A Tour on 3rd Party tools

1. DevExpress

2. Infragistics

3. Telerik

4. ComponentOne
5. Caphyan Advance Installer.
6. Aqua Data Studio (for E-R designs)
7. Farpoint Spread
8. DotNet Bars
9. Source Offsite
10. Multisite
11. ClearQuest
12. Fiddler
13. Report Sharp Shooter

Top Reasons why we should have requirement documents?

1. Requirements are not features. You simply must know what your users must have to do their jobs. Distinguish thoughtfully and carefully between what is needed and what the vendor is offering. At the same time, you must be able to factor into the requirements documentation other considerations, such as budget limitations and regulatory constraints. You will need to train your users how to specify their requirements, which takes tact, training, and patience. A request usually starts with: "All I really need is " and then wanders away. A vague or ambiguous statement -- regardless of its intent -- will consume user time, IT time and cause some other loss, such as the opportunity to do another project. This issue is methodology neutral: Agile methods will have the same problem if user time is not focused and users are not trained. You cannot fulfill the requirements until they're precise and complete and you understand why they're important to the business.
2. Features are not requirements. Eliminate decisions made by squeaky wheels --- sometimes referred to as "design by whine" -- where the loudest department gets the most resources. Your goal is to make certain that business decisions made with regard to requirements (and their associated expenditures) will generate the return you're expecting. Start by working backward, to match the problems solved with existing software to identify the problems that must be and can be solved only with new software. Don't lose anything you have now that is essential to the business; it's easy to forget "hidden" requirements that oftentimes are taken for granted or ignored.
3. Work with your resources and manage with discipline. Developing an effective requirements document costs money and managing resources requires discipline. A politically expedient decision, even if it's cost effective in the short run but is not the right decision in the long run, will cost time and money -- eventually. From a strategic point of view, ask if the requirements process itself is going to cost more than it's worth. You will find that using the enterprise requirements documentation process will help you avoid useless meetings, which saves time and money, but more about that later. When the appropriate constituents are communicating with each other, they accept the value of their participation because they can track the project's payback to the entire organization.
4. On-going documentation is essential. It's necessary that you continue to manage your requirements, because sometimes internal departments continue to push for a project, application or feature that was denied in the last upgrade or purchase. Perhaps it wasn't worth the cost, or its payback wasn't acceptable to the enterprise as a whole. By maintaining continuity in your requirements documentation, you can see why a prior request was denied. If the reason hasn't changed, it's likely there is no need to investigate it again -- and you can avoid bringing in a "new" solution to solve an equally "new" problem. Referencing prior documentation also can help you eliminate ongoing costs for applications and hardware that are no longer used.
5. Identify and understand the workarounds and desk drawer systems. You need to understand what in your current application made a workaround or desk drawer system an attractive solution. Then, make certain the upgrade eliminates these systems and their causes, with this caveat: You might learn, in the course of such an investigation, that a certain desk drawer system has a unique function or user, and that it's best left alone.
6. Focus your users' attention. You want to learn from them what can be done better, faster or more efficiently, but realize that users don't always know their current business needs. In fact, users at different levels of an organization have different perceptions of business needs, priority and urgency. They tend to segregate by department or management level " dismissing problems because "it's not an IT issue" -- but an effective requirements document requires integration and impact analysis for all departments. Know, too, that the needs of other stakeholders (senior management, operations personnel and human resources, for example) must be considered. User frustration comes from asking for one thing and receiving another; help them articulate their needs carefully and fully. When what a user asks for is not possible, feasible or within budget, say so, because unmet expectations foster dissatisfaction. Always ask what's the relative value of a new "requirement" to avoid spending $10 to save a dime. And don't forget: users take what they have for granted, so make sure it's carried forward in the new request.
7. Benefit from "outside" expertise. An objective outsider, can, will and should ask the questions an insider cannot. What works? What doesn't? What frequent requests create problems because they're difficult to meet with the existing application? That's the outsider's function -- to have no vested interest in how the problem is solved. It's a common pitfall in requirements documentation to describe a problem in terms of its supposed solution -- which might not be the best, or most cost effective, approach. An outsider also can provide useful guidance on how to handle regulatory requirements that affect information systems, but that most business people are not aware of, such as the prohibition against retail businesses retaining credit card numbers after a transaction.
8. Consider your upgrade as an investment and apply metrics to it. A comprehensive requirements document will help you decide if the benefits of the new application or upgrade justify the cost. How much more productive can the organization be with the upgrade, compared to the current application? Track paybacks for projects and information assets to determine when to re-invest or stop further investment. It's possible that an application was a good investment -- at the time. When it was installed, perhaps it saved every one of your 5,000 clerks 30 minutes a day -- but today, you have 5 clerks and it saves them three minutes a day. That feature probably isn't worth the cost. And some stand alone features -- such as desktop publishing -- aren't needed now, thanks to the tools available in word processing applications.
9. Save time. Reduce rework by spending time in the requirements gathering and analysis process, where it's much cheaper to eliminate a "need" than realizing it costs too much (or isn't cost effective) downstream in the design, development or application stage. Time invested in the initial steps of the process provides more time for decision making at the right time. More control of the process will help keep it moving; participants will know what to expect as you move from blue sky thinking to brainstorming to understanding to decision making. Tracking the results of your meetings will document what you've agreed to do and what you've agreed not to do and who made the decision.
10. Save money. To start, you will eliminate ongoing costs for applications and hardware that your requirements information gathering tells you are used no longer. With the right subject matter experts and decision makers involved at the right time, you will not be able to move forward on ideas that sound promising but contain potentially expensive problems that would have to be solved later in the process -- and at a greater cost. You will open many avenues to managing costs, whether it's eliminating unnecessary systems, consolidating a value-added system or evaluating long-term versus short-term value. You might learn, for example, that in the year required to acquire and install a new system the opportunity to use it will disappear. One of the most promising benefits of developing enterprise requirements is the strong possibility you will establish standard solutions to many of your seemingly "unique" problems, obviating the need for custom solutions -- and that can be a real time and money saver.

Version Control with Tortoise SVN (part - 2)

TortoiseSVN Visual Studio Integration

Download the following Subversion.zip files which contains some settings files for VS2005 and VS2008
http://www.esnips.com/doc/6fe6f31e-ae60-4838-9be7-6fe22661d0e0/subversionhttp://www.esnips.com/SignInAction.ns?action=forcesign

The settings file gives you a new toolbar, a new menu, and new items on the context menus in the solution view.  You get some nice TortoiseSVN standard icons to make it even easier.

This all works with Visual Studio 2005 and 2008 (and even the Express Editions), along with a standard installation of TortoiseSVN.  Unless you want to edit the commandline in the External Tools I recommend installing TortoiseSVN to the default location.

It’s quick to set up, just go to your “Tools” menu and choose “Import and Export Settings” and follow the instructions. Ensure the tick box for which settings to import are all ticked.  If the settings don’t work first time, try again, as Visual Studio can be a bit flaky when loading.  It will replace your External Tools because they have to be stored in the correct numbered slot due to the way they are implemented in Visual Studio.

Files contained in the Subversion.zip files :

SubversionMenu.vssettings

This is a settings file for Visual Studio 2008.  This adds a menu to the IDE for TortoiseSVN with the appropriate icons.

SubversionMenuToolbar.vssettings

This is a settings file for Visual Studio 2008.  This adds a menu for TortoiseSVN as well as a toolbar using the appropriate icons.

SubversionMenuToolbarContexts.vssettings

This is a settings file for Visual Studio 2008.  This adds not only the menu and toolbar, but also adds the items to the appropriate context menus for files and solutions.

SubversionMenuToolbarContextsVS2005.vssettings

This provides the menu, toolbar and context menus for TortoiseSVN in Visual Studio 2005.

SubversionInstall.vbs

Use this file if you want the external tools only.  These will be appended to the list, otherwise use the settings files.  Don’t use in addition to the settings file.

This simply installs a set of External Tools into Visual Studio for common TortoiseSVN operations. It can be installed on versions above Visual Studio.NET (version 7.0). Currently it is configured for Visual Studio 2008 (version 9.0), to make it work on other versions change the variable “strVisualStudioVersionNumber” as outlined in the file’s comments.

Also, if you have installed TortoiseSVN in a non-default location, make sure that you change the variable “strTortoiseSVNBin” to the correct binary path. Make sure that the backslashes are doubled up.

Supported TortoiseSVN operations

The following Subversion/TortoiseSVN features are covered in the integration:

• Commit - Commit the files to the repository
• Update - Update the current working version
• History - Get the history for the selected file
• Diff - Get the diff compared to the base version
• Blame - Find out who committed the crimes in the file
• Revert - Undo local changes
• Modifications - Check to see if any files have been modified
• Edit Conflicts - Edit the conflicts that arise from merging/updating
• Resolve - Mark the file as resolved for conflicts
• Repository - View the repository on the server
• Project History - Get the history of the entire project
• Add Solution - Add the solution being edited to source control
• Branch/Tag - Perform a branch or tag on the current working copy
• Settings - Set up TortoiseSVN

 

References:
1. tortoiseSVN
https://www.projects.dev2dev.bea.com/Subversion%20Clients/TortoiseSVN.html

Some Diff/Merge Tools

If the tools we provide don't do what you need, try one of the many open-source or commercial programs available. Everyone has their own favourites, and this list is by no means complete, but here are a few that you might consider:
WinMerge
WinMerge [http://winmerge.sourceforge.net/] is a great open-source diff tool which can also handle directories.
Perforce Merge
Perforce is a commercial RCS, but you can download the diff/merge tool for free. Get more information from Perforce [http://www.perforce.com/perforce/products/merge.html].

KDiff3
KDiff3 is a free diff tool which can also handle directories. You can download it from here [http://kdiff3.sf.net/].
ExamDiff
ExamDiff Standard is freeware. It can handle files but not directories. ExamDiff Pro is share ware and adds a number of goodies including directory diff and editing capability. In both flavours, version 3.2 and above can handle unicode. You can download them from PrestoSoft [http://www.prestosoft.com/].
Beyond Compare
Similar to ExamDiff Pro, this is an excellent shareware diff tool which can handle directory diffs and unicode. Download it from Scooter Software http://www.scootersoftware.com/].
Araxis Merge
Araxis Merge is a useful commercial tool for diff and merging both files and folders. It does three-way comparision in merges and has synchronization links to use if you've changed the order of functions. Download it from Araxis [http://www.araxis.com/merge/index.html].
SciTE
This text editor includes syntax colouring for unified diffs, making them much easier to read. Download it from Scintilla [http://www.scintilla.org/SciTEDownload.html].
Notepad2
Notepad2 is designed as a replacement for the standard Windows Notepad program, and is based on the Scintilla open-source edit control. As well as being good for viewing unified diffs, it is much better than the Windows notepad for most jobs. Download it for free here [http://www.flos-freeware.ch/notepad2.html].