Ruthlessly Helpful

Stephen Ritchie's offerings of ruthlessly helpful software engineering practices.

Category Archives: Unit Testing

Thank You Upstate New York Users Groups

Leave a comment Posted by on December 28, 2012

In November I traveled to Upstate New York to present at four .NET Users Group. Here’s the overview:

  1. The first stop was in Albany on Monday, Nov. 12th to present at the Tech Valley Users Group (TVUG) meeting.
  2. On Tuesday night I was in Syracuse presenting at the Central New York .NET Developer Group meeting.
  3. On Wednesday night I was in Rochester presenting at the Visual Developers of Upstate New York meeting.
  4. Finally, on Thursday night I was in Buffalo presenting at the Microsoft Developers in Western New York meeting.

 

Many Belated Thank Yous

I realize it is belated, but I’d like to extend a very big and heartfelt thank you to the organizers of these users groups for putting together a great series of meetings.

Thank you to Stephanie Carino from Apress for connecting me with the organizers. I really appreciate all the help with all the public relations, the swag, the promotion codes, the raffle copies of my book, and for the tweets and re-tweets.

Slides and Code Samples

My presentations are available on SlideShare under my RuthlessHelp account, but if you are looking for something specific then here are the four presentations:

  1. An Overview of .NET Best Practices
  2. Overcoming the Obstacles, Pitfalls, and Dangers of Unit Testing
  3. Advanced Code Analysis with .NET
  4. An Overview of .NET Best Practices

All the code samples can be found on GitHub under my RuthlessHelp account: https://github.com/ruthlesshelp/Presentations

Please Rate Me

If you attended one of these presentations, please rate me at SpeakerRate:

  1. Rate: An Overview of .NET Best Practices (Albany, 12-Nov)
  2. Rate: Overcoming the Obstacles, Pitfalls, and Dangers of Unit Testing
  3. Rate: Advanced Code Analysis with .NET
  4. Rate: An Overview of .NET Best Practices (Buffalo, 15-Nov)

You can also rate me at INETA: http://ineta.org/Speakers/SearchCommunitySpeakers.aspx?SpeakerId=b7b92f6b-ac28-413f-9baf-9764ff95be79

Automated Testing, Best Practices, Books, CI, Code Analysis, Development, Presentations, Pro .NET Best Practices, Unit Testing

Thank You Philly.NET Code Camp 2012.1

Leave a comment Posted by on May 14, 2012

Philly.NET Code Camp 2012.1Although I have been developing software for more than 20 years, on Saturday I went to my first Code Camp. I delivered one session at Philly.NET Code Camp on the topic of Automated Unit and Integration Testing with Databases.

I was amazed. Philly.NET Code Camp is like a mini TechEd. I am impressed at how professionally everything was done. Registration, content, food, facilities, etc. This group knows how to put on a code camp. It is a testament to the capability and dedication of Philly.NET; it’s leadership and members. Keep up the good work. Thank you for an awesome day. I cannot wait for the next one.

Slides

Here are the slides, available through SlideShare.

Automated Testing with Databases

View more PowerPoint from Stephen Ritchie

Sample Code

The sample code from my session (Tools track, 1:40 PM) is available here:

Also, please review the requirements for using the code samples in the section below the slides.

Requirements For The Code Samples

To use the sample code, you need to create the Lender.Slos database. The following are the expectations and requirements needed to create the database.

The sample code assumes you have Microsoft SQL Server Express 2008 R2 installed on your development machine. The server name used throughout is (local)\SQLExpress. Although the sample code will probably work on other/earlier versions of SQL Server, that has not been verified. Also, if you use another server instance then you will need to change the server name in all the connection strings.

Under the 0_Database folder there are database scripts, which are used to create the database schema. For the sake of simplicity there are a few command files that use MSBuild to run the database scripts, automate the build, and automate running the tests. These batch files assume you defined the following environment variables:

  • MSBuildRoot is the path to MSBuild.exe — For example, C:\Windows\Microsoft.NET\Framework64\v4.0.30319
  • SqlToolsRoot is the path to sqlcmd.exe — For example, C:\Program Files\Microsoft SQL Server\100\Tools\Binn

The DbCreate.SqlExpress.Lender.Slos.bat command file creates the database on the (local)\SQLExpress server.

With the database created and the environment variables set, run the Lender.Slos.CreateScripts.bat command file to execute all the SQL create scripts in the correct order. If you prefer to run the scripts manually then you will find them in the $_Database\Scripts\Create folder. The script_run_order.txt file lists the proper order to run the scripts. If all the scripts run properly there will be three tables (Individual, Student and Application) and twelve stored procedures (a set of four CRUD stored procedures for each of the tables) in the database.

Automated Testing, NDbUnit, Presentations, Unit Testing

Automated Unit and Integration Testing with NDbUnit

Leave a comment Posted by on May 3, 2012

The sample code from the May 1, 2012 presentation of Automated Unit and Integration Testing with NDbUnit to the CMAP Main Meeting is available on GitHub: https://github.com/ruthlesshelp/Presentations. Please review the requirements for using the code samples in the section below the slides.

The slides are available on SlideShare.

Automated Unit and Integration Testing with NDbUnit

View more PowerPoint from ruthlesshelp

Requirements For The Code Samples

To use the sample code, you need to create the Lender.Slos database. The following are the expectations and requirements needed to create the database.

The sample code assumes you have Microsoft SQL Server Express 2008 R2 installed on your development machine. The server name used throughout is (local)\SQLExpress. Although the sample code will probably work on other/earlier versions of SQL Server, that has not been verified. Also, if you use another server instance then you will need to change the server name in all the connection strings.

The sample code for this presentation is within the NDbUnit folder.

Under the 0_Database folder there are database scripts, which are used to create the database schema. For the sake of simplicity there are a few command files that use MSBuild to run the database scripts, automate the build, and automate running the tests. These batch files assume you defined the following environment variables:

  • MSBuildRoot is the path to MSBuild.exe — For example, C:\Windows\Microsoft.NET\Framework64\v4.0.30319
  • SqlToolsRoot is the path to sqlcmd.exe — For example, C:\Program Files\Microsoft SQL Server\100\Tools\Binn

The DbCreate.SqlExpress.Lender.Slos.bat command file creates the database on the (local)\SQLExpress server.

With the database created and the environment variables set, run the Lender.Slos.CreateScripts.bat command file to execute all the SQL create scripts in the correct order. If you prefer to run the scripts manually then you will find them in the $_Database\Scripts\Create folder. The script_run_order.txt file lists the proper order to run the scripts. If all the scripts run properly there will be three tables (Individual, Student and Application) and twelve stored procedures (a set of four CRUD stored procedures for each of the tables) in the database.

Automated Testing, NDbUnit, Unit Testing

Keep Your Privates Private

1 Comment Posted by on March 2, 2012

Often I am asked variations on this question: Should I unit test private methods?

The Visual Studio Team Test blog describes the Publicize testing technique in Visual Studio as one way to unit test private methods. There are other methods.

As a rule of thumb: Do not unit test private methods.

Encapsulation

The concept of encapsulation means that a class’s internal state and behavior should remain “unpublished”. Any instance of that class is only manipulated through the exposed properties and methods.

The class “publishes” properties and methods by using the C# keywords: public, protected, and internal.

The one keyword that says “keep out” is private. Only the class itself needs to know about this property or method. Since any unit test ensures that the code works as intended, the idea of some outside code testing a private method is unconventional. A private method is not intended to be externally visible, even to test code.

However, the question goes deeper than unconventional. Is it unwise to unit test private methods?

Yes. It is unwise to unit test private methods.

Brittle Unit Tests

When you refactor the code-under-test, and the private methods are significantly changed, then the test code testing private methods must be refactored. This inhibits the refactoring of the class-under-test.

It should be straightforward to refactor a class when no public properties or methods are impacted. Private properties and methods, because they are not intended to be directly called, should be allowed to freely and easily change. A lot of test code that directly calls private members causes headaches.

Avoid testing the internal semantics of a class. It is the published semantics that you want to test.

Zombie Code

Some dead code is only kept alive by the test methods that call it.

If only the public interface is tested, private methods are only called thorough public-method test coverage. Any private method or branch within the private method that cannot be reached through test coverage is dead code. Private method testing short-circuits this analysis.

Yes, these are my views on what might be a hot topic to some. There are other arguments, pro and con, many of which are covered in this article: http://www.codeproject.com/Articles/9715/How-to-Test-Private-and-Protected-methods-in-NET

Automated Testing, Best Practices, Unit Testing