bencoffman.com/blog - UnitTesting

In work the other day we started to debate the best way to "mock" a web service. The two ideas we boiled down to were either to create another web service exactly the same as the original, except have it consume the data from a text file or to have a flag in the existing data layer, trigger the code to read data from a text file locally, thus removing an additional dependency created by making a second web service

What I came up with was this. We needed to decide what we were testing?

Are we testing
1. To make sure the code can deal with the data correctly?
Or
2. Are we testing to see if our code can connect to the web service?

Since we would like to specify our own data, I believe this makes it pretty clear. We are testing to make sure we can deal with the data correctly.

The first argument stated, that by making a new web service, in which we specify the data, you are not only testing that the web service can connect but it can consume it correctly. I believe this is where their thinking was different than mine.

In most web best practices you create a “N-Tier” architecture. Meaning that one of the tiers is dedicated to connecting to the database and returning a data-dump. The reason this is done is because most programming architects like to believe they can sub in one data consumption tier with another, example, getting data from Oracle as opposed to DB2 or getting data from a web service as opposed to a MSSQL database, without causing any issues in the logic of the code. Thus, how the data is retrieve is of little importance, but how it’s processed is where the real brains are and have high importance. All of this being the point of separating this data layer tier from the business logic tier. Now understanding this aspect you also have to think in the mind of a tester. Testers want to remove as many external dependencies on the code as possible. Testers don’t care about the connection a web service makes, they only care about the data it returns. Testers want to control that data and put in their own to test for every scenario and they want to do it with as few dependencies as possible. Therefore introducing a new web service that sits on some other server is not favorable. Now in order to test code you have to maintain another server, another web service and worry about any network issues between the tester and that web service. However most would feel best practice would be to inject the data right into the code nearly removing the data layer. This removes numerous external dependencies and makes the code easier to maintain as it gets passed from generation to generation of developer that comes and goes from the company.

The next question is, what would be the best way to inject this data? To make the example easy I just added some additional code in the data layer where we consume the web service and made it look at a flag I set in the web.config. If it says true, it hits the web service, if the flag says false it consumes a local text file, the path of which is also specified in the web.config. This is a down and dirty way of doing it. There are more elegant ways such as using “Constructor Based Dependency Injection,” and using nMock.

If you would like more information on the correct way to test a web service this blog post provides some very solid and good examples.

Sunday, August 01, 2010 4:55:34 PM (Central Standard Time, UTC-06:00)

Comments [0] - Trackback
.Net | Unit Testing

NUnit, NUnit Mocks, NMock2, DotNetMock, and Selenium : Pragmatic Unit Testing In C# with NUnit

If Scott Hanselman lives and die's by unit tests, why don't we all just fall in line? It seems the nerd community, has an uncanny ability to adopt silly things quickly. Things like xkcd.com or the idea of ninja's. I have yet to laugh at one xkcd or understand how ninja's are relative in any shape or form, because of this I felt I needed to read up on unit tests, specifically for C#, to find out if it's just hype or this is something development shops with a strong QA team really need to look at.

I read two books that covered the topic of unit testing. The first book was Foundations of Programming (recommended by Scottie H. himself and is free) and the second is Pragmatic Unit Testing In C# with NUnit. Both of them start off with the same old song and dance on how you might have up front costs of introducing unit tests to your code, but the stability these tests provide over the duration of your codes lifetime will cause such dramatic cost savings for the company, it would be foolish not to explore the idea. What a compelling sales pitch, a pitch salesmen, for just about any technology, have used since the beginning of technology in businesses. I'll cut all the used car salesman tactics out and state the most intriguing argument to unit test. It increases code stability and it's easy.

The next question I asked myself: What do I exactly test in the code-base I am working on? In Pragmatic Unit Testing (PUT) they give us an acronym to use in order to answer this question. BICEP.

BICEP, breaks down as such.

Boundary Tests

Inversion Tests

Cross Check Tests

Error Tests

Performance Tests

These are the 5 major aspects one should test, according to PUT and it provides unit testers with a place to start. The next major topic in discussing how to test code is decoupling one piece of code to another. Does your code talk to a middleware? How do you test if middleware is not done creating your service to consume or if middleware is down? In steps NUnit Mocks, NMock2, and DotNetMock. These 3 mock frameworks provide the developer with the ability to feed your tests predefined values, values decided by you. Without going into how to use these mock frameworks, I believe that outside of a few isolated situations they should not be used. The entire purpose of testing your code is to test that you are getting information back that fits the criteria you are looking for. If this information, that is beyond your control, changes on whatever level for whatever reason, you as a developer need to know. Putting in mock objects hides this.

Since I work for a web shop, the topic of web UI unit tests interested me. PUT recommend using Selenium. This makes sense because it still uses the nunit style of testing keeping all your tests to one testing style. Selenium seems a bit cumbersome in comparison to WaitN or iMacro, but I feel keeping all your testing in the same style outweighs the cons of not using Selenium. The more desperate testing sources you introduce, the more confusing it is for an outsider to step in and see the whole picture when learning the code, especially when it's not contained in a single solution.

Finally, I recommend reading both of the books mentioned, but lets be honest most of us care so little about unit testing we'll be lucky to read all of 1 of these books let alone all of both. If this is the case I recommend PUT, while the first few chapters read like the high school teacher striving to gain his students social acceptance, it's an easy read and you can jump into the book at nearly any chapter and get the exact information you are looking for on unit testing. This is something I wish all programming books could achieve.

Wednesday, November 11, 2009 3:12:32 PM (Central Standard Time, UTC-06:00)

Comments [0] - Trackback
.Net | readings | Unit Testing