http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660John - I'm undecided at this point. At what point do unit tests stop being unit tests and start being integration tests, policy tests, etc. Does this matter? How hard is it to write code to reflect IL and verify it in the general case? I think it's pretty hard in the general case. There's existing tools like NDepend that can do that with a simple query. There's a point you'll probably get to where writing code to statically analyse code causes much more friction than does using a static analysis tool--but then you've got some static anlayis code in unit tests and some in unit tests. In reality, not all of Oren's suggestions are static analysis; and some would be hard to get specific project policy into a static analyser. e.g. what does service mean and how do you get that policy into a static analyser? I'm wondering, in cases like this, when should existing tools that allow you to do this (statically analyze code) be used, and when you should write unit tests? http://ayende.com/3302/actively-enforce-your-conventions#comment11http://ayende.com/3302/actively-enforce-your-conventions#comment11Tue, 06 May 2008 13:43:19 GMTI try to do the same. It's particularly helpful when working in large (or even small, for that matter) distributed teams. On a previous project we had quite a few database design conventions codified as unit tests (e.g. no use of Identity columns except for the following known tables). XMLSerializable is another one I've done, also ensuring that XmlInclude attribute is present on base classes if you're using polymorphic messages. http://ayende.com/3302/actively-enforce-your-conventions#comment10http://ayende.com/3302/actively-enforce-your-conventions#comment10Tue, 06 May 2008 11:50:41 GMTAs per normal - you are a step ahead Oren ... thanks for the post, it inspired me to prevent an annoying bug in my own code with a guard test! http://ayende.com/3302/actively-enforce-your-conventions#comment9http://ayende.com/3302/actively-enforce-your-conventions#comment9Tue, 06 May 2008 08:53:41 GMTPeter - does it matter much either way? I know Reflection and Nunit, so it was easy to write the check that way. Another consideration is your organization's infrastructure. We have CI that runs unit tests on every commit, but not FxCop (yet, anyway). So it makes more sense to use unit tests. http://ayende.com/3302/actively-enforce-your-conventions#comment8http://ayende.com/3302/actively-enforce-your-conventions#comment8Tue, 06 May 2008 03:04:14 GMTWhen you start getting into reflection in unit tests, it's starting to sound a lot like static code analysis. Do you think policies like this could live in custom code analysis rules (either an FxCop rule or a CQL query?). Do you think this type of thing should be validated in unit tests? http://ayende.com/3302/actively-enforce-your-conventions#comment7http://ayende.com/3302/actively-enforce-your-conventions#comment7Mon, 05 May 2008 20:28:32 GMTGood ideas, Ayende! One I came up with a while back was for our convention of creating enums for database code values, which we keep in their own table by category. I wrote a unit test that reflected on the enums and retrieved all the code values from the db, then ensured that they matched up. http://ayende.com/3302/actively-enforce-your-conventions#comment6http://ayende.com/3302/actively-enforce-your-conventions#comment6Mon, 05 May 2008 17:08:43 GMTRequest is a generic term here. Can be web request, SOAP call, the time to handle single message, etc http://ayende.com/3302/actively-enforce-your-conventions#comment5http://ayende.com/3302/actively-enforce-your-conventions#comment5Mon, 05 May 2008 16:20:42 GMT It could looks like (notice the numerous ways to match what classes are services or messages FROM Somewhere DeriveFrom "ABaseClass" Implements "AnInterface" HasAttribute "AnAttributeClass" NameLike "ARegExToMatchByName" NameLike "ARegExToMatchByFullName" (i.e namespace prefix included) ... # All services should have a Dispose() method - add a Dispose abstract method to AbstractService WARN IF Count IF SELECT TYPES FROM NAMESPACES "YourNamespaceWhereMessageAreDefined" WHERE (DeriveFrom "YourServiceBaseClass" OR HasAttribute "YourServiceAttribute" OR NameLike "RegExToMatchServiceClass") AND !Implements "System.IDisposable" # All messages should be serializable - create a test that scan the message assemblies and check for non serializable messages. WARN IF Count IF SELECT TYPES FROM NAMESPACES "YourNamespaceWhereMessageAreDefined" WHERE (DeriveFrom "YourMessageBaseClass" OR HasAttribute "YourMessageAttribute" OR NameLike "RegExToMatchMessageClass") AND !IsSerializable # The interface assembly may not contain logic - add a test that would fail if it find a class with a method on the interface assembly WARN IF Count IF SELECT ASSEMBLIES WHERE (HasAttribute "YourInterfaceOnlyAttribute" OR NameLike "RegExToMatchInterfaceOnlyAsm") AND NbILInstructions > 0 http://ayende.com/3302/actively-enforce-your-conventions#comment4http://ayende.com/3302/actively-enforce-your-conventions#comment4Mon, 05 May 2008 16:03:37 GMTWhen you refer to a 'request' taking 100ms or less, is this a WebRequest or a database request? http://ayende.com/3302/actively-enforce-your-conventions#comment3http://ayende.com/3302/actively-enforce-your-conventions#comment3Mon, 05 May 2008 15:43:43 GMTPatrick, I haven't thought about that, but it seems obvious when I do think about it. http://ayende.com/3302/actively-enforce-your-conventions#comment2http://ayende.com/3302/actively-enforce-your-conventions#comment2Mon, 05 May 2008 14:36:17 GMTDid you look at Code Query Language rules? It can handle all your 'static' convention such as: # All services should have a Dispose() method - add a Dispose abstract method to AbstractService # All messages should be serializable - create a test that scan the message assemblies and check for non serializable messages. The interface assembly may not contain logic - add a test that would fail if it find a class with a method on the interface assembly. http://ayende.com/3302/actively-enforce-your-conventions#comment1http://ayende.com/3302/actively-enforce-your-conventions#comment1Mon, 05 May 2008 11:19:51 GMT