I am using the latest edition of Service Factory - Modeling Edition (VS2008). I've created a number of FaultContracts in my DataContract model, and utilized them in my ServiceContract model. The generated code for the ServiceContract does not include the namespace or action for the FaultContract, e.g.
A few weeks ago I stumbled upon a tool called Pex from the Microsoft Research Labs: "Pex finds interesting input-output values of your methods, which you can save as a small test suite with high code coverage." Not having much time to spend exploring it, I was fortunate to have time to attend a Twin Cities Developers Guild meeting tonight and hear a talk on on how to use the tool, which now has me jump started. First a few highlights of what I learned (without cribbing too much from Jason Bock's presentation), and then sample results from the method in my last post.
My team often starts Tuesday morning status meetings with a round of win/learn/fun - a team-building exercise where each person gets to mention an exciting "win", something they learned in the last week, or just something fun. Several weeks ago someone brought up C# Extension Methods as a learn. I could see the potential, but I didn't immediately think of any practical examples.
You have an ASP.Net web service/site that needs to access network resources, and IIS is running in a service account that you do not want to have access to those resources.
Create a custom network account and setup a separate application pool. Microsoft article How To: Create a Service Account for an ASP.NET 2.0 Application outlines some pros/cons and gives a few alternatives, as well as giving the basic instructions. However, I found that these instructions had to be modified with inclusion of a few extra security rules. Steps:
Here's a really dumb scenario that will illustrate a point about the usefulness of the "red, green, refactor" approach to testing and coding. Here's the functionality - need to test whether or not a string has a value other than 1. Let's say I write a method before any tests:
You have an table with encrypted columns. In the ADO.Net Entity Framework, you can't directly write an update to this table, since it does not handle the encryption commands. Furthermore, the framework will not return meaningful information, since it cannot decrypt the data. Finding the solution to this has been an adventure.
What's wrong with this code? There are unnecessary lines. So? Why care about unnecessary lines? Because it shows that the programmer was not really thinking about what he was doing.
MyObject obj = someList.Find(delegate(MyObject test)
{
if (test.Id.Equals(packageId))
{
return true;
}
else
{
return false;
}
});
you have a method that logs a message using the Microsoft Patterns & Practices Enterprise Library Logging Block, and you would like to write an automated unit test for it in NUnit (or Team System — solution is easily adapted). Logging to a flat file doesn't work; the file is still open when you try to read it to verify that the message has been logged. Logging to the database doesn't work; it seems the log isn't written to the database immediately. And so forth. Is there an in-memory way of reading the logged message?
A few months after I first purchased it, I am still reading xUnit Test Patterns. Been reading a few pages every day - now on page 590 with a few hundred to go!
I have finally arrived at the point where the author describes the pattern Test Specific Subclass (TSS). This is a pattern we have used extensively in our testing at the office, so that we can access protected methods in our classes. However, we stumbled upon it on our own, well before reading anyone else's suggestions on how to apply it. That's the nature of patterns for you.
We just upgraded our servers to support .Net 3.x, so at last I'm able to start migrating some of my code. I haven't taken a close look at all the features available yet, but one that caught my eye and initially excited me is automatic properties. However, I had two conflicting reactions:
Well, this article addresses a primary benefit: this facilitates refactoring. If, for instance, we find later on that we need something more advanced than a simple get or set statement, then we can add it without breaking the interface. I'm sold.
