November 27, 2007
As I was creating a few properties in the Application settings class in Visual Studio 2008, I noticed a new dropdown as part of the screen. It allows for the changing of the access modifier for the Settings Class, it can now be either internal or Public. Now there is a way to expose these settings externally. By default they are Internal, but I made this one public.
For more information on using the settings class, http://msdn2.microsoft.com/en-us/library/cftf714c(VS.90).aspx
November 19, 2007
As an avid fan of CodeRush, I am awed at the extensibility that this product provides. One area is in the extensibility of creating custom plugins. I took the time this weekend to understand how to build a custom metric after seeing a training video up at the DevExpress site. The metric I chose to build was one that counted the number of returns in a method. This metric will be useful in code reviews to see if a method may be too complex based upon the number of returns.
Here are my high level steps:
1. Create a new plugin project.
2. Drag and drop a CodeMetricProvider from the toolbox and set the following properties
3. Implement the method for getting the metric value, it should look something like this:
private void metricReturnsCounter_GetMetricValue(object sender, DevExpress.CodeRush.Extensions.GetMetricValueEventArgs e)
{
if (e.LanguageElement is Member)
{
Member member = (Member)e.LanguageElement;
int counter = 0;
foreach (LanguageElement element in member.AllFlowBreaks)
{
if (element.ElementType == LanguageElementType.Return)
counter++;
}
e.Value = counter;
}
}
That’s it, the final result looks like this in the metrics window of CodeRush:
As you can see, it looks like there is a lot of work that can be done on a couple of these methods, to clean the number of returns up.
November 17, 2007
Update: removed my mock object from the new test for clarity.
I have reevaluated my approach to how to write a test to catch exceptions. NUnit has an attribute for ExpectedException which I have been using to test exceptions in my code. I ran across an instance of a specialized Exception the other day, that had custom parameters as part of the exception. Using the ExpectedException attribute, I was able to test that the Exception was thrown, but not the custom parameters that were part of the Exception. For example of an Exception with custom parameters, check out the framework MembershipCreateUserException.
Here is the setup code to put the tests in context.
DynamicMock mockService;
IAuthenticationContract agent;
CustomMembershipProvider provider;
[SetUp]
public void Setup()
{
mockService = new DynamicMock(typeof(IAuthenticationContract));
agent = (IAuthenticationContract)mockService.MockInstance;
provider = new CustomMembershipProvider(agent);
}
[Test]
[ExpectedException(typeof(MembershipCreateUserException))]
public void ValidateUserReturnsFalseWithBlankPassword()
{
mockService.ExpectNoCall(“ValidateCredentials”);
provider.ValidateUser(“Someone”, “”);
mockService.Verify();
}
What I am expecting is that the provider.ValidateUser() call will throw the exception. This does work as expected, but at this point I only get that a type of MembershipCreateUserException was called. I cannot inspect any properties of the exception at this point, but the test passes.
[Test]
public void ValidateUserReturnsFalseWithBlankPassword()
{
try
{
provider.ValidateUser(“Someone”, “”);
Assert.Fail(“The Blank Password should have thrown an Error”);
}
catch (MembershipCreateUserException ex)
{
Assert.AreEqual(MembershipCreateStatus.InvalidPassword, ex.StatusCode);
}
}
Notice that my intent is also to just ensure the the provider.ValidateUser() call is going to fail. I am catching this exception that is expected and validating the Exception status. This last test more explicitly states my intent of the test.
November 13, 2007
I really never understood the difference of why one would use a static readonly property vs. a const, until now. I very much dislike having string values hardcoded and would rather make them strongly typed to use throughout the application. This works great, unless those constants can’t be determined until runtime. So here is my solution, make them public static readonly members that read config file settings to help get the value at runtime.
Example:
public static class MyPages
{
/// <summary>
/// Login Page Url
/// </summary>
public static readonly string Login = GetUrl(“/Login/Login.aspx”);
private static string GetUrl(string page)
{
return Settings.Default.WebRoot + page;
}
Notice that I have a static class with a private method that goes out to the settings and updates the url with a value from the settings class. This allows the URL to be configurable at runtime, for instance, the url code become relative, rootlevel, or other means.
Your thoughts?
