work: .net aop c sharp C# functional tests postsharp Selenium
by toni
leave a comment
AOP, NUnit and Selenium: clever screenshots of failures
Last week I did struggle finding out why a test was failing only on our Cruise box, only in the Cruise build.
I wanted to get a screenshot of each failing tests, and I think I found a clever solution: aop.
We already use PostSharp on our code base for logging, transaction demarcation and hibernate session support, so I wrote a simple annotation for our acceptance tests:
-
using System;
-
using PostSharp.Laos;
-
-
namespace Web.UI.AcceptanceTests
-
{
-
[Serializable]
-
public class ScreenCaptureAttribute : OnExceptionAspect
-
{
-
public override void OnException(MethodExecutionEventArgs eventArgs)
-
{
-
SeleniumManager.Selenium.CaptureScreenshot(string.Format("C:\\{0}.jpg", eventArgs.Method.Name));
-
}
-
}
-
}
Every time a test will throw an Exception Selenium will take a screenshot of the screen: pretty simple.
The only caveat is that it won’t work if Cruise is running as a service, and to get a decent result you’ll probably need to maximize the web browser windows.
Fan Programming Language
I’m just having a look to Fan and it seems quite a cool language, soon more posts on this.
Fan Programming Language: “Portability
Write code portable to both the Java VM and the .NET CLR.
Familiar Syntax
Java and C# programmers will feel at home with Fan’s curly brace syntax.
Concurrency
Tackle concurrency with built-in immutability, message passing, and REST oriented transactional memory.
Static and Dynamic Typing
Don’t like the extremes – take the middle of the road.
Elegant APIs
We’re quite obsessive about providing all the key features required for a standard library, but with much less surface area than the APIs found in Java or .NET.
Object Oriented
Everything is an object.
Mixins
Interfaces but with implementation.
Functional
Functions and closures are baked in.
Serialization
Built-in ‘JSON like’ serialization syntax makes Fan ideal for declarative programming too.
REST
Model data with a unified namespace of resources identified with URIs.
Some (N)Hibernate Learnings
After at least two years of Hibernate and NHibernate experience I can say that I know what’s going on, I can’t still say that I know very well (N)Hibernate but I wanna share some learnings.
- The logger is your best friend:
When sometimes goes wrong, the logger (or at least a profiler) will help you, it’s awesome to play with a database like we play with objects but I have the feeling that sometimes we forget that on a couple of layers below we are doing some good old SQL! - (N)Hibernate is not meant for:
- Bulk data manipulations: use sqlBulkCopy in (.net) or upgrade to a version > 3.1.1 on Java Hibernate
- Free developers from understanding the database: it’s nice to hide the DB structure but the DB is there, and it’s not OO!
- Free developers from understanding (N)Hibernate.
I sow many times in developers this approach: entusiasm followed by criticism followed by hate
It’s very easy to do simple things and terrible then to fix bugs or understand some stack traces. It’s a great library and it’s not easy to use. A copy of hibernate in action or of nhibernate in action should be always present in a team playing with it. - Let you forget the profiler: as mentioned before it’s the best way to understand the complexity of your queries, it’s easy to end up with a cartesian product result from a query or execute unuseful queries, especially when playing with multiple joins and criteria queries.
How do you build your projects?
Recently we migrated all our build scripts from a combination of bat files + msbuild to a couple of NAnt build files.
There are some reasons for this and some nice outcomes.
Reasons
First of all we wanted to have the same build scripts for Development, CI, QA, UAT and production Environment.
On the Dev machines we need to build, test and install few services (ms services, a web service and a web app).
On Cruise same as above but no installation of the services and, indeed some publishing of the artifacts.
The QA environment is as close as possible as the UAT/Production: it just needs installation scripts and a way to get the latest artifacts published by Cruise.
Using the same script gave us a great confidence when going to production: scripts were used every day by the QA, no surprises when going live.
We got completely rid of all the .bat files for 2 main reasons: they become messy after 1 year of patches/fixes/modifications and we can’t really achieve the goal of one script for all as we wanted.
After a short investigation on alternatives to bat+msbuild (boobs and rake) we went for nant.
We found boobs quite difficult to use and install (you need to build some libraries, install boo, etc…), in other words it does not came for free. Rake is a cool solution, we didn’t choose that cos 1) we were too lazy to install ruby everywhere (in production especially could be a problem) 2) our build, even if includes a client app, four services, a web app and a web services is fairly simple.
Nant is really a good translation from the Java Ant. It’s actually more than a one to one translation, it has more features and it’s somehow more powerful.
I really liked the functions for example. And the contrib project is plenty of nice, useful tasks ready to use.
Another important improvement on the build scripts was on the database scripts.
Again, migrated from few bat files to one script for all the needed tasks.
We had a lot of satisfaction using dbdeploy.net, it really speeds up the work, especially in the QA environment migrating the DB schema to the latest version keeping the data in.
Outcomes
Life easier for everybody: instead of calling a bat files with some parameters we had a file of properties (not a lot of properties, convention over configuration!) for each environment, it’s now harder to fail an installation. It’s also more clear of what’s going on thanks to the nant output log.
Maintenance it’s easier. There are only two files that you need to know. Tasks are pretty short and responsibilities isolated.
We kept also a low lever of dependencies avoiding imports and more than two level of dependency.
Sometimes rewriting everything from scratch is much easier than refactoring / patching.
It has been also interesting to write a build file after one year of development, usually it’s one of the first things you do in your project.
My suggestion is: if your build script causes problems, waste of time or if it just smells and it’s not clear what’s doing, try to spike out a different solution, the benefit could be enormous.