System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, SqlConnection owningObject, Boolean withFailover) at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject, Boolean withFailover) at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart) at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance) at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance) at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection) at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection, DbConnectionPool pool, DbConnectionOptions options) at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject) at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject) at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject) at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection) at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory) at System.Data.SqlClient.SqlConnection.Open() at System.Data.Common.DbDataAdapter.QuietOpen(IDbConnection connection, ConnectionState& originalState) at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, String srcTable) at ftp_controls.Common_.Utility_.GetCustomRegPropertiesByUrl(String url) Visual Studio Magazine - Write Unit Tests
Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

Click here to receive your FREE subscription to Visual Studio Magazine

email article
printer friendly
get the code
more resources

Write Unit Tests
Make sure changes you make to your apps don't cause unwanted side effects.
by Nick Smith

Technology Toolbox: VB.NET, C#

You might be familiar with the all-too-common experience of making a change to an application, testing it, and releasing it, only to discover that the change you made broke something elsewhere in the app. Unless you test your application fully, you can't be sure changes you make won't affect another part of the system. In some organizations, quality assurance (QA) departments are responsible for catching knock-on effects. However, the release-to-QA, fix, release-back-to-QA cycle can take a considerable amount of time. Besides, not everyone has a QA department. You need a methodology for making changes that minimizes the risk of unforeseen side effects. Enter unit testing.

ADVERTISEMENT

The premise for unit testing is that you write discrete tests to test your application's functionality. You run your unit tests after you've made any changes to the system. If all tests pass, you can be confident the application still executes as you intended. You still have no guarantee it will, because the change might cause a problem a unit test doesn't cover. And unit tests can't replace system tests QA departments write and perform. But unit testing is a useful safeguard.

You write tests for each method belonging to a class that exhibits some type of measurable effect. The scope of method types you'll test is up to you. I usually write tests for each public/protected method and for any private methods I think play an important role in the class's functionality. You can group unit tests together to form test suites, which a unit-testing tool can then execute automatically.

My introduction to unit testing came when I began working on an Extreme Programming (XP) project (see the sidebar, "Take Programming to an Extreme"). I'd been writing tests for my code for several years, but most had been full component tests. Each test that I'd written had performed some complex processing and returned a measurable result. With unit tests, you write fine-grained tests for each piece of functionality. For example, if you have a component consisting of one public class and 10 private classes, you write unit tests for all 11 classes, not only the one public class.

You need to use an automated unit-testing tool to write effective unit tests. A huge range of tools isn't available for .NET at the moment. For the purpose of this article, you'll use dotUnit—an open source port of JUnit, a popular Java unit-testing tool you can download (see Resources). (If you search for "unit test" at www.opensource.net, you'll see that unit-testing tools are available for most languages, including ASP.NET). This article's example code is in C# (you can download it and a VB.NET version here).

Back to top













Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTPOnline Home