Testing and Internal Implementation in .NET

Switching back and forth between Java and .NET lets you see some of the differences between the two platforms more easily. This happened to me the other day when I switched from Java to .NET and was writing Unit Tests. In Java, the access modifiers include public, private, protected and default. In C# they are public, private, protected and internal. In general, the public, private access modifiers are very similar. Protected is slightly different in that Java allows both derived classes as well as classes in the same package to access those elements where C# only allows derived classes to access them. Where things diverge more is in the default/internal differences. Default in java restricts access to the same package while internal in C# restricts access to the same Assembly (generally a single DLL).

What does this have to do with testing you might ask?

It’s a good OO design principle to expose only those things that are part of the contract to a class or package and to leave the implementation hidden as much as possible. This is called encapsulation. You can make methods private or default/internal. You can make entire classes default/internal and only publicly expose an interface that clients need to use.

A common practice in the Java world is to mimic the package layout of your main source code in your test code. When you mimic that layout then your test classes and implementation classes end up being in the same packages. Because of this your test classes can access all those default members to test them. In C# because it’s not based on a namespace, but rather an Assembly this doesn’t work.

Luckily there’s an easy workaround.

In the AssemblyInfo.cs of your main project add:

[assembly: InternalsVisibleTo("someOther.AssemblyName.Test")]

Where SomeOther.AssemblyName.Test is the name of the Assembly that contains your tests for the target assembly. Then the test code can access internal details of the assembly. And you can easily test the things that other calling code might not have access to.

Using Groovy AST to Add Common Properties to Grails Domain Classes

Groovy offers a lot of runtime meta-programming capabilities that allow you to add reusable functionality in a shared fashion. Grails plugins make use of this ability to enhance your project. One of the things that you can’t do with runtime meta-programming in Grails is to add persistent Hibernate properties to your domain classes. If you want to add a persistent property in a plugin (or otherwise using meta-programming) for your Grails project you have to make use of “compile-time” meta-programming. In Groovy this is done with AST Transformations.

(If you are unfamiliar with the concept of the Abstract Syntax Tree, see the Wikipedia article on Abstract Syntax Tree.)

AST Transformations are made up of two parts: (1) An annotation and (2) an ASTTransformation implementation. During compilation the Groovy compiler finds all of the Annotations and calls the ASTTransformation implementation for the annotation passing in information about.

To create your own Transformation you start by creating an Annotation. The key to the annotation working is that your annotation has to itself be annotated with @GroovyASTTransformationClass. The values passed to the GroovyASTTransformationClass define the Transformation that will be called on classes, methods or other code prior to it being compiled.

Example Annotation


package net.zorched.grails.effectivity;

import org.codehaus.groovy.transform.GroovyASTTransformationClass;
import java.lang.annotation.*;

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@GroovyASTTransformationClass({"net.zorched.grails.effectivity.EffectivizeASTTransformation"})
public @interface Effectivize {
}

Notice the reference to net.zorched.grails.effectivity.EffectivizeASTTransformation. That’s the important part because it defines the class that will be used to perform the transformation.

Example Transformation


package net.zorched.grails.effectivity;

import org.codehaus.groovy.ast.*;
import org.codehaus.groovy.ast.builder.AstBuilder;
import org.codehaus.groovy.ast.expr.*;
import org.codehaus.groovy.ast.stmt.*;
import org.codehaus.groovy.control.*;
import org.codehaus.groovy.transform.*;
import java.util.*;
import static org.springframework.asm.Opcodes.*;

@GroovyASTTransformation(phase = CompilePhase.CANONICALIZATION)
public class EffectivizeASTTransformation implements ASTTransformation {

// This is the main method to implement from ASTTransformation that is called by the compiler
public void visit(ASTNode[] nodes, SourceUnit sourceUnit) {
if (null == nodes) return;
if (null == nodes[0]) return;
if (null == nodes[1]) return;
if (!(nodes[0] instanceof AnnotationNode)) return;

ClassNode cNode = (ClassNode) nodes[1];
addProperty(cNode, "effectiveStart", Date.class, createGenerateStartMethodCall())
addProperty(cNode, "effectiveEnd", Date.class, createGenerateEndMethodCall())

}

// This method returns an expression that is used to initialize the newly created property
private Expression createGenerateStartMethodCall() {
return new ConstructorCallExpression(new ClassNode(Date.class), ArgumentListExpression.EMPTY_ARGUMENTS);
}

private Expression createGenerateEndMethodCall() {
return new MethodCallExpression(
new ConstructorCallExpression(new ClassNode(Date.class), ArgumentListExpression.EMPTY_ARGUMENTS),
"parse",
new ArgumentListExpression(new ConstantExpression("yyyy/MM/dd"), new ConstantExpression("2099/12/31")));
}

// This method adds a new property to the class. Groovy automatically handles adding the getters and setters so you
// don't have to create special methods for those
private void addProperty(ClassNode cNode, String propertyName, Class propertyType, Expression initialValue) {
FieldNode field = new FieldNode(
propertyName,
ACC_PRIVATE,
new ClassNode(propertyType),
new ClassNode(cNode.getClass()),
initialValue
);

cNode.addProperty(new PropertyNode(field, ACC_PUBLIC, null, null));
}
}

This example code gets called for each annotated class and adds two new Date properties called effectiveStart and effectiveEnd to it. Those properties are seen by Grails and Hibernate and will become persistent and behave the same as if you typed them directly in your Domain.

It’s a lot of work to add a simple property to a class, but if you’re looking to consistently add properties and constraints across many Grails Domain classes, this is the way to do it.

DRYing Grails Criteria Queries

When you’re writing code, Don’t Repeat Yourself. Now say that 5 times. *rimshot*

One of the things that I find myself repeating a lot of in many business apps is queries. It’s common to have a rule or filter that applies to many different cases. I came across such a situation recently and wanted to figure out a way to share that filter across many different queries. This is what I came up with for keeping those Criteria DRY.

To start with, I’ll use an example of an Article. This could be a blog post or a newspaper article. One of the rules of the system is that Articles need to be published before they are visible by end users. Because of this seemingly simple rule, every time we query for Articles, we will need to check the published flag. If you get a lot of queries, that ends up being a lot of repetition.

Here’s our example domain class:

package net.zorched.domain
class Article {
String name
String slug
String category

boolean published

static constraints = {
name(blank: false)
slug(nullable: true)
}
}

Now we need to add a query that will retrieve our domain instance by its slug (a slug is a publishing term for a short name given to an article, in the web world it has become a term often used for a search engine optimization technique that uses the title instead of an artificial ID). To perform that query we might write something like this on the Article class:

static getBySlug(String slug) {
withCriteria(uniqueResult:true) {
and {
eq('approved', true)
eq(' slug', slug)
}
}
}

We want to query based on the slug, but we also want to only allow a published Article to be shown. This would allow us to unpublish an article if necessary. Without the approved filter, if the link had gotten out, people could still view the article.

Next we decide we want to list all of the Articles in a particular category so we write something like this, again filtering by the approved flag.

static findAllByCategory(String category) {
withCriteria() {
and {
eq('approved', true)
eq('category', category)
}
}
}

Two simple examples like this might not be that big of a deal. But you can easily see how this would grow if you added more custom queries or if you had some more complicated filtering logic. Another common case would be if you had the same filter across many different domain objects. (What if the Article had attachments and comments all of which needed their own approval?) What you need is a way to share that logic among multiple withCriteria calls.

The trick to this is understanding how withCriteria and createCriteria work in GORM. They are both implemented using a custom class called HibernateCriteriaBuilder. That class invokes the closures that you pass to it on itself. Sounds confusing. Basically the elements in the closure of your criteria queries get executed as if the were called on an instance of HibernateCriteriaBuilder.

e.g.

withCriteria {
eq('a', 1)
like('b', '%foo%')
}

would be the equivalent of calling something like:


def builder = new HibernateCriteriaBuilder(...)
builder.eq('a', 1)
builder.like('b', '%foo%')

That little bit of knowledge allow you to reach into your meta programming bag of tricks and add new calls to the HibernateCriteriaBuilder. Every Class in groovy has a metaClass that is used to extend types of that Class. In this case we’ll add a Closure that will combine our criteria with other criteria like so:

HibernateCriteriaBuilder.metaClass.published = { Closure c ->
and {
eq('published', true)
c()
}
}

This ands together our eq call with all of the other parts of the passed in closure.
Now we can put the whole thing together into a domain class with a reusable filter.


package net.zorched.domain

import grails.orm.HibernateCriteriaBuilder

class Article {

static {
// monkey patch HibernateCriteriaBuilder to have a reusable 'published' filter
HibernateCriteriaBuilder.metaClass.published = { Closure c ->
and {
eq('published', true)
c()
}
}
}

String name
String slug
String category

boolean published
Date datePublished

def publish() {
published = true
datePublished = new Date()
}

static def createSlug(n) {
return n.replaceAll('[^A-Za-z0-9\\s]','')
.replaceAll('\\s','-')
.toLowerCase()
}

static findAllApprovedByCategory(String category) {
withCriteria {
published {
eq('category', category)
}
}
}

static getBySlug(String slug) {
withCriteria(uniqueResult:true) {
published {
eq(' slug', slug)
}
}
}

static constraints = {
name(blank: false)
datePublished(nullable: true)
slug(nullable: true)
}
}

And there you have it. Do you have any other techniques that can be used to DRY criteria?

Coffee DSL Redone With Meta-Programming

In a previous post I wrote about DSLs as Jargon. I implemented a simple Coffee DSL that would allow code to parse an order written by a human and turn it into a domain model. I used a fairly basic method_missing structure to capture the values.

There’s a much better way to do it in Ruby with meta-programming. Meta-programming allows you to write code to write code. You program your programming. In this case we can create the syntax of Coffee using a meta-programming technique.

dsl_attr :size, %w(venti grande tall)

This is us programming the class to say: “If someone calls a method venti, grande, or tall on our object they mean that they are telling us the size of the coffee, so store that value as the size”. So now we can write our Coffee class like this:

# CoffeeDSL.rb
# This is the input from the user, likely read from a file
# or input through a user interface of some sort
CoffeeInput = "venti nonfat whip latte"

class Coffee
dsl_attr :size, %w(venti grande tall)
dsl_attr :whipped, %w(whip nowhip)
dsl_attr :caffinated, %w(caf decaf halfcaf)
dsl_attr :type, %w(regular latte cappachino)
dsl_attr :milks, %w(milk nonfat soy)

def order
params = ''
params += milks + ' ' if milks?
params += caffinated + ' ' if caffinated?
params += whipped + ' ' if whipped?
print "Ordering coffee: #{size} #{params}#{type}\n"
end

def load
# turn one line into multi-line "method calls"
cleaned = CoffeeInput.gsub(/\s+/, "\n")
self.instance_eval(cleaned)
end
end

We are essentially configuring the class in code. We could add extra values as well, such as a default value, required validation, any number of things. We then just need to implement the dsl_attr using meta-programming. That can be done in the Module in Ruby which makes that available to all classes in the system.


class Module
def dsl_attr(param_name, values)
attr param_name
class_eval "def #{param_name}?; @#{param_name}; end"
values.each do |val|
define_method("#{val}") do
instance_eval %{
@#{param_name} = '#{val}'
}
end
end
end
end

Now when you run the code it captures all of the values that are parsed from the input and puts them into your object as meaningful values.

c = Coffee.new
c.load
c.order

I did the same DSL in Groovy and thought I could attempt to do it more justice using meta-programming as well. In Groovy, meta-programming is done with the ExpandoMetaClass – no, I didn’t make that up. Each Class has a metaClass property that gets you access to that types’ ExpandoMetaClass instance. You can then add properties and methods and whatnot to it. This has the effect of making the properties or methods callable on an instance of that type.


ExpandoMetaClass.enableGlobally() // have to do this to get inheritance of dslAttr

Object.metaClass.dslAttr << {String param_name, values ->
def clazz = delegate
clazz.metaClass."${param_name}" = null
values.each() { val ->
clazz.metaClass."${val}" << {-> clazz."${param_name}" = "${val}" }
}
}

class Coffee {
def Coffee() {
dslAttr("size", ['venti', 'tall', 'grande'])
dslAttr("whipped", ['whip', 'nowhip'])
dslAttr("caffinated", ['caf', 'decaf', 'halfcaf'])
dslAttr("type", ['regular', 'latte', 'cappachino'])
dslAttr("milks", ['milk', 'nonfat', 'soy'])
}

def order() {
def params = ''
if (null != getMilks()) params += "${getMilks()} "
if (null != getCaffinated()) params += "${getCaffinated()} "
if (null != getWhipped()) params += "${getWhipped()} "
println "Ordering coffee: ${getSize()} ${params}${getType()}\n"
}

def load(String input) {
// turn one line into multi-line "method calls"
def cleaned = input.split(/\s+/)
cleaned.each() { meth -> this.&"${meth}"() }
}
}

def c = new Coffee()
c.load("venti nonfat whip latte")
c.order()

I’m not sure if there is a better way to do this or not. Ideally I would like to have the dslAttr add something to the Coffee metaClass instead of just adding stuff to the instances, but this seems to do the trick for now.

The Ruby and Groovy implementations become fairly similar at this point. It’s a great way to reduce the amount of boilerplate code you would need to normally write to implement this kind of thing in less dynamic languages.