Unit Testing friction...

I'm having a problem trying to achieve something that seems quite trivial and was wondering if I am going totally the wrong way about it.

I am trying to write a unit test against a method that essentially essentially does an in memory linq query over a collection of Lightspeed entities. Here is a simplified version of the method that I am trying to test.

 public IEnumerable<ClassStateTransition> ValidTransitions(IEnumerable<ClassStateTransition> transitions, ClassState currentState)

{

var validTransitions = transitions.Where(transition => transition.FromClassStateId == currentState.Id);

return validTransitions;

}

ClassState and ClassStateTransition are LightSpeed domain objects.

In my unit test i want to new up a collection of ClassStateTransition and a ClassState object and set the currentState.Id on the object so i can alter the behaviour of my unit test to pass. But there is no way of setting the Id on a Lightspeed entity.

One suggestion I guess is Is that I could add another identifier column to my database that is not used by lightspeed that i could use in my query, but this feels like a pollution of my data model simply to accomodate a unit test.

Thanks in advance.

To be honest, our usual practice for unit testing is to use a database.  I know purists would not approve but we've found it generally easier and more convenient, and it's not too hard to make it reliable using scripts and transactions to recreate the database at the start of a test run and to keep it unchanged between tests.

However, I realise this could be a pain especially for running tests outside the continuous integration environment (e.g. if you're using TestDriven.NET to run single tests off the right-click menu).

A possible alternative is to override the Entity.GeneratedId method in test builds only (using conditional compilation).  This provides you with full control over ID allocation.

Something we should probably look at is providing an IdentityMethod for test support, that just generates sequential IDs without reference to the database.  We'd welcome any feedback you have on this or other ideas that would make the unit testing scenario easier for you.

 Hi Ivan,

Yeah that's a shame, I guess am probably more in the purist's camp  and like to make more of a distinction between what I regard as a unit and an integration test. Certainly if the code i am testing is fairly far removed from the code that actually makes the calls off to the database I want to isolate that code from hitting a real database. I know you guys are the first to admit that Lightspeed is opinionated software and this is an example of me trying to bend it to my will .

I've followed some of the other threads on your reasons why you don't allow people to set an entities Id and I do understand your justification for it.

One suggestion, and I don't know how hard this would be to implement, but could the LightSpeed Framework include some sort of generic Entity Factory for unit testing purposes?

 Cheers,

 Stu

Hi

I was about to post my own post in the forum, but since I found it was already here added by someone else I guess I can just add to this dialog.

In our product we are using nightly builds with tests. For the GUI involving the Lightspeed O/R mapper we have so far been using Integration tests that is doing what you are proposing. I.e. use the database in the tests. From what I understand Lightspeed does not support Unit Tests using the common definition o fast running tests (milliseconds execution time,  basically meaning no time consuming I/O operation).

I am no TDD purist, but we have discovered the hard way that Integration Tests as the only fine grained Tests methodology is not a doable approach. After a year of development of our product we have a code base of some 20.000 lines of code. This means that the amount of Integration tests will render to long feedback and debugging chain of broken tests. The result is often that the build remains broken for days which is devastating basically.

So essentially, we realise we have to move starting using more Unit Tests also in our GUI subsystem that is using Lightspeed, i.e. mocking the database. But Lightspeed does not support this as far as I can see. .

In order to mock a Respository method, eg, OrderRepository.CreateOrder, you would have to provide a mock object that this method return. This mock object would need to have a positive ID and a EntityState=Default.

Would it be possible for you to open up the possiblity to set these values explicitly? Or are you afraid that it would be missused?  

We have recently added some limited hooks for this, such as the GeneratedId and OnMockSavingEntity methods, and marking properties as virtual in the designer, but we're aware that we need to provide much more systematic support for mocking and faking entities and the entity lifecycle.  We don't want to just open this up to allowing arbitrary code to set the ID and entity state at arbitrary times, because experience teaches us that this *will* confuse people (especially new users).

We have therefore recently begun some preliminary work on providing some more positive testing hooks that will allow safe setup of entities without encouraging dangerous modification.  At the moment this is proof of concept so we can't commit to particular APIs or release dates, but it is an area we are actively working on.

Ok, thanks. that's good news. I'd be great if you would let me know when this is available in a nightly build. And I gladly volunteer to receiving a beta version if guys want some early feedback.

Thanks Tobias - we will definitely get you involved with our 3.0 testing :) Currently our intention isnt to ship this via the nightlies for the time being, but we will be spinning up a beta cycle soon enough so we will let you know once there is something to play with :)

Jeremy

 Great! Just let me know, and I'll be here with my bug finding typing hands..