A UnitTest that analyzes your source code.

The nice thing about this is that you can codify team rules.  Rather than saying, "Never, EVER do xyz.", and hoping that no programmers ever do xyz, you can just write a UnitTest that guarantees that it won't happen.

Examples of things SourceTest''''''s can check for:
* '''The CodingStyle''' - As a bonus, this helps when writing other SourceTest's, because then you can make assumptions about the way the code will look.
* '''Rudimentary security checks''' - For example, perl's string system() is generally always a bad idea.  You can write a SourceTest to make sure all system()'s use the array form.
* consistent spelling
* compiler/interpreter warnings
* external source analyzing tools (e.g. lint for CeeLanguage)
* ...''lots of other stuff.  (TODO)''

See CookieMonster

----
I have created a source test on my current project, related to Java object serialization. The project uses Prevayler, which stores commands and objects that must be Serializable and need to define serialVersionUID correctly. In order to do that, I wrote a test that scans a given package and uses reflection to verify that serialVersionUID exists and is public, static, final, long. Very neat thing to do, for the first time. -- JbRainsberger

----
I HaveThisPattern. I created a base class object from which all of our model objects (all simple data holders) derived. This base class had an abstract isEmpty() method. The contract for this method was that if all contained objects were null (or in the case of a String == "" as well), then isEmpty had to return true. This was for the persistence layer. So I used reflection to create an object of the correct type, called each setter in turn, and saw if the isEmpty() method changed from true to false. This worked wonderfully, although the testing code was a bit hard to grok. I think this prevented a lot of bugs in the model objects.

The same set of tests also tested code conventions (if there was a list of objects contained within the object, then there had to exist certain methods to access it). We had several subsystems based on the same pattern, so this was to make it easier to grok unknown code.

Personally, I wouldn't go too far down this road. I think if you select specific examples which will eliminate bugs, then you're sorted. --MatthewFarwell
----
CategoryTesting