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.

Error Readout:
System.IndexOutOfRangeException:

Fix:
I encountered the above error when I tried to run the query,

SELECT MAX(expression )
FROM tables
WHERE predicates;

and then loop through the results using a datareader with code like this,

while(rdr.Read())
{
      someLabel.Items.Add(rdr["ColumnName"].ToString());
}

I got the error above, because when you do a "max" sql query it doesn't return any column header.

All you need to do is give the sql result set a column header.

SELECT MAX(expression) as "ColumnName" 
FROM table 
where predicates;

Explanation:
This is another one of my bone head mistakes. It's such a simple little thing I overlook, and gets me so disappointed in myself when I realize I spent time trying to figure this out. It's generally followed by me looking over my shoulder and seeing if any of my peers saw it. I'm mostly blogging this in hopes I won't make a silly mistake like this again.

Why is it always the baby errors that hang me up the most? It can never be something deep in the CLR, or possibly find a mistake in .Net. Nope, noway, not gonna happen .Net is pretty solid...for the most part.

Error Readout:
None, it's not an error silly.

The Problem:
When I debug, and look at a string that contains my file path I see 2 backslashs (escape characters) in my string when I only wanted 1.

The Solution:
It's nothing, don't worry about it, that's just the way Visual Studio "debug" shows your path when you catch it while debugging.  When the path is used in the code for the file system there will only be 1 backslash and it will work correctly.

This is such a stupid little thing, but for some reason every once in a blue moon, I forget and freak out on why it's doing this, thus wasting a solid five minutes of my life. I put this post up in hopes I will never forget again and that if someone happens to Google this, my post will pop up and help them move on quickly....maybe only wasting 1 to 2 minutes. :)

Apple expects to sell 1 million to 1.4 million iPhones this weekend, this is excluding the 900,000 pre-orders. It has the possibilty to be the biggest selling product release in history!

http://online.wsj.com/article/SB10001424052748704629804575325661775151320.html?mod=WSJ_Tech_LEADTop

UPDATE: They sold 1.7 million. Apple's most successful product release in it's history.

Error Readout:
Incorrect syntax near ')'

The Problem:
When I was trying to pass in getdate() as a parameter to execute a stored procedure i got the above error.

Example:
exec dbo.storedProcedure
    @param1 = '8D8DF077-7491-491B-AFA2-8F088821A073',
    @param2 = '8D8DF077-7491-491B-AFA2-8F088821A073',
    @param3 = 'Market: SAP 4 Eva',
    @param4 = getdate()


The Solution:
A sql execute statement can't pass a function such as getdate() in through a parameter. To fix this either:

1. Put getdate() directly in your sql statement that resides in the stored procedure
2. Pass a null if your table definition allows you to.
3. Create a temp variable store the value of getdate() in that variable and pass in that variable through the datetime parameter.