Subscribe: Brian Sherwin's Blog
http://geekswithblogs.net/bsherwin/rss.aspx
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
code  config file  config  configuration  file  global asax  log net  log  net config  net  test  tests  web config  web 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Brian Sherwin's Blog

Brian Sherwin's Blog



Moving at the Speed of .Net



Copyright: Brian Sherwin
 



Watch your procedure cache when using parameters

Thu, 21 Feb 2008 22:30:15 GMT

Originally posted on: http://geekswithblogs.net/bsherwin/archive/2008/02/21/119875.aspx

Dan Guzman had an enlightening post on how SQL server caches ad-hoc queries when using inline parameters.  Basically the gist is that if your values for any given paramter changes you get variability in you cached procedure.  However, if you specify the SqlDbType when adding your parameters, you can avoid this whole problem.

Technorati Tags:
(image) (image)



Moving your Log4Net configuration out of web.config with ASP.NET 2.0 web sites.

Fri, 15 Feb 2008 17:43:38 GMT

Originally posted on: http://geekswithblogs.net/bsherwin/archive/2008/02/15/119657.aspxI was working with log4net recently and had put a lot of the configuration information in the web.config file for an ASP.NET 2.0 web site.  Ideally, this was not what I wanted because I want to be able to change the configuration of the log4net without recycling the web application (a side effect of changing the web.config file).  After spending a fair amount of time reading out on the web--a lot of people said it can't be done. It took me piecing together multiple settings to finally get this to work. However, I have the following dilemmas: First, I didn't find all of the information in one place. Second, I didn't bookmark the information I did find to give proper credit where it is due. Therefore, if this has a resemblance to your work--I'm sorry--but I wanted to write this post to put it all in one place. So my goal was to put it here in one place. Step 1: Create the log4net.config file.  That's right, break out the configuration into a file (call it whatever you want, but I call it log4net.config). Copy all of your log4net configuration settings out of your web.config file and put them here. (Don't just copy and paste--cut out everything related to log4net from the web.config file).   Step 2: Tell the application to configure log4net using this config file. There are really two spots for this. First, the global.asax and second the assemblyInfo.cs file. Note, that most of the time you will start out with a global.asax file with all of the code inline. For whatever reason, the only way I could get this to work was to break the global.asax up to use a code-behind and then ass the assemblyInfo.cs file.  So it ends up looking like this. global.asax: <%@ Application Language="C#" Inherits="GlobalAsax" %> global.asax.cs (in your App_Code folder): using System; using System.Web; public class GlobalAsax : HttpApplication { // you may have lots of other code here void Application_Start(object sender, EventArgs e) { log4net.Config.XmlConfigurator.Configure(); } }Now that you have your application calling log4net's configuration, you can set an attribute in your assembly info so that log4net knows where to look for the configuration file. AssemblyInfo.cs (in your App_Code folder): [assembly: log4net.Config.XmlConfigurator(ConfigFile = "log4net.config", Watch = true)] The watch flag tells log4net to keep an eye on the configuration file for potential changes.  This is helpful if you want to change the configuration from logging everthing to errors only during the middle of your testing. Step 3: Log to your hearts content! Now that you have your configuration set up, start logging everything from Information to Debug to Fatal Errors. This sure beats doing "Response.WriteLine" BTW, the reason I posted the UdpAppender, was that I have found this one to be incredibly useful when using Apache's "Chainsaw" log reader to view your logging without having to keep searching through log files. Technorati Tags: ASP.NET, log4net [...]



What are you really testing?

Thu, 14 Feb 2008 04:05:18 GMT

Originally posted on: http://geekswithblogs.net/bsherwin/archive/2008/02/13/119561.aspx

So I was working today on some code that has a fair amount of automagically generated tests.  Now I must first say that generated code is cool, but generated tests...not so much.  If you claim tests for code coverage...go for it. If it is about TDD, you can't really "generate" the tests can you. (That would be TGD--test generated development)  The tests are supposed to come before the code...OK, that's an argument for another post.

The point of this post is that when you are doing tests, you have to be sure of what you are testing. If you are testing data access, test data access. If you are testing workflow, test workflow. But please, please don't try to test that your workflow correctly writes to the database. Your tests take way too long.

For example, if you have an integration test that tests your ORM mappings then fine, you have 4 tests: Insert, Update, Delete, Read. If, however, you have a need to test that a user can't delete a record from the database, do you really need that test to set up a record in the database just to be sure that he can't delete it? A resounding NO. The test should be about validating the permission of the user. Our code generation had blurred the line of what we were really testing and thus introduced tests that interacted with the database, but really had no reason to even think about the database.

Now I get to spend my morning tomorrow refactoring the tests to ignore the database completely and simply set the permissions for the current user and then Assert that the user permissions appropriately allow/deny.  8 seconds vs 3 milliseconds. I know which tests I want to run "red/green/refactor"!

Keep in mind, your tests should follow along with the Single Responsibility Principle. It should test one thing and should not depend on a whole lot of setup to make it happen. That's what mocks, stubs and fakes are for. Keeping your tests lean will keep the time to run them to a minimum. You really lose out on a lot of the advantages of TDD when you generate your tests automatically (including the "right-click" generation in VS2008). The Design in TDD comes from thinking about what you are testing and driving what you code you actually write.

(image) (image)