Today I implemented the ConfigurationSection stuff in .NET you can use to interject your custom configuration structures into config files like web.config and app.config. I wanted to test not only my implementation, but the classes that rely on the configuration but it wasn't exactly clear how I could get ConfigurationManager to load an arbitrary configuration.
The solution is quite simple and I figured it out after a bit of trial and error. What got me was that I had a custom configuration file in a child directory of my unit test project("WebServices") and I had set the configuration file's build action to "Copy Always". I had thought it would end up in "bin\Debug" but it correctly ended up in "bin\Debug\WebServices" so that's an important thing to keep in mind.
Outsmarting ConfigurationManager also requires that you have an accompanying file (empty text file works) that the configuration applies to. So here's what the start of my [now working] test looks like:
private static RequestHandlerSection _section;
[TestFixtureSetUp]
public void Setup()
{
using (var sw =
File.CreateText(".\\WebServices\\RequestHandlerTests")
)
{
sw.Close();
}
var config = ConfigurationManager.OpenExeConfiguration(
".\\WebServices\\RequestHandlerTests"
);
_section = (RequestHandlerSection)
config.Sections[RequestHandlerSection.Name];
}
[Test]
public void WorkDamnYouTest()
{
Assert.IsNotNull(_section);
Assert.IsNotEmpty(_section.Security);
}
}
Ideally at some point in the future ConfigurationManager could get a Load(string xml) or some such so we don't have to deal with this nonsense. While I could add one with an extension method I'd like to see it get into the framework to improve unit testability.
Three things have been bugging me lately about C#. Well one since I started using C# coming from writing a ton of unmaintainable Perl code. What C# needs:
- unless
- implies
- templates
unless
Unless is just a reversed if statement. Its actually quite simple and in some situations it improves code readability. This is personal opinion more so than anything else, but I feel strongly about it. Compare:
if (!property.CanRead)
continue;
to:
continue unless propery.CanRead;
So what it does is remove the negation from the if test (I mean, it is unless after all, isn't it?). It just flows better. "Oh, continue unless this condition is met."
implies
Extracting interfaces from existing classes is certainly easier with ReSharper, but I want more. I don't want to have to maintain separate interface files when the interfaces will match the implementation all of the time. I understand when you make interfaces and then code the implementation to them however that approach isn't always needed. I'll give a specific example: unit testing. I've started using StructureMap and Moq to significantly improve the quality of our tests, but in order to do that I had to StructureMap pluginify all of the IBATIS mappers we have written. In 100% of the cases the implementation of the mappers are the interfaces of the mappers, and now that I've gone and done this anytime a change needs to be made to a concrete mapper the interface will need to be updated as well - the dependency has been essentially reversed. I think this scenario will become more common as more people work to improve their unit tests, so I'd like to see something where:
public class PersonMapper : IPersonMapper
{
public Person Select(int id) { return null; }
public IList<Person> SelectAll() { return null; }
public void Create(Person p) { }
public void Update(Person p) { }
public void Delete(Person p) { }
}
public interface IPersonMapper
{
Person Select(int id);
IList<Person> SelectAll();
void Create(Person p);
void Update(Person p);
void Delete(Person p);
}
becomes:
public class PersonMapper implies IPersonMapper
{
public Person Select(int id) { return null; }
public IList<Person> SelectAll() { return null; }
public void Create(Person p) { }
public void Update(Person p) { }
public void Delete(Person p) { }
}
So this isn't a solution for contract by design, its just the opposite, a tightly bound interface to a concrete class. But what it does do is reduce lines of code and increases maintainability and decreases the pain of writing good unit tests to a degree. And yes, a tool could be used to do this (I've wrote one in fact), but I'm talking maintainability and ease of use here!
templates
C# generics are very nice, but they are not templates. Many people who can better articulate the problem than I have argued for them so I'll just post my recent headache as my argument of why I want templates:
private static volatile INodeMapper nodeMapper;
public static INodeMapper Node()
{
if (nodeMapper == null)
{
lock (typeof(INodeMapper))
{
if (nodeMapper == null)
nodeMapper = ObjectFactory.GetInstance<INodeMapper>();
}
}
return nodeMapper;
}
Because nodeMapper is declared volatile you cannot pass it using ref (or even out which would be less ideal than ref).
So imagine that code having to be written for every entity in your database. Again, a tool can do it, but that's not the correct answer to the problem. A preprocessor template here would be the only way to do what I want to accomplish in a sane manner. Until then I've used partial classes to break our mappers down to more maintainable levels (about 2000 lines of repetitious code into several smaller files alphabetically organized).
The command to get a performance counter to recur on a set daily schedule under Windows Server 2000 and 2003 is:
logman update yourlogname -b 08/12/2008 23:00:00
-e 08/13/2008 09:00:00 -r
So the -r at the end causes it to recur on every date after 8/12-8/13 in those same hour windows (8/13-8/14, 8/14-8/15, et al.).
Server 2008 of course allows you to schedule the logging via the GUI.