Practical TDD/BDD in CSLA

I think he meant to say BDD – Behavior Driven Development.  It is a technique for people who are moving into Test Driven Development to show that you are not writing tests but rather documenting and assuring behavior, or use case assumptions in your tests.  That is why they are called Behaviors and no tests.  There is also a set of rules one has to follow when practicing BDD:

http://en.wikipedia.org/wiki/Behavior_driven_development

To me this could be very interesting to many Csla developers, as I believe that Csla framework itself encourages Behavior driven design, of an OO system. 

Nermin

What is DBB?

I think you are right about BDD.  I would point to it as an easy way/concept to introduce folks into TDD world, but not go with BDD tools/frameworks.

Well the problem with Mocking in CSLA is that it uses “Mobile Object” concept (which is the coolest part about it -  the thing that puts it way above anything else).  Mobile object meaning that client requests the object (client context), and then the server instantiates it configures it (server context).

How does one Mock something (like DAL components) that does not exist in the context in which you instantiate your object?  Moreover, most of the mock frameworks require that the component that is being mocked is visible from the outside and is passed as a reference to the object that we are going to unit test.  Csla objects encapsulates everything.  You do not pass dependencies to your Factory Method.  And even if you would, is it possible to pass references to DAL objects and then serialize them over network to the server.  Most of the ADO.Net infrastructure is not serializible, and honestly the whole idea sounds just to complicated.

So is there a solution to this – yes there is!

In your test configuration you will have to assure that you are running SimpleDataPortal request are passed to local context.  Then you will need a Top Gun mocking framework: TypeMock.Net (The just changed the name to Isolator).  There is a free version and a commercial one.  The difference with TypeMock is that it uses Profiler API so it can intercept ANY object instantiation.  Therefore it if you use TypeMock/Isolator you do not have to worry about having to “inject ” dependencies.

There are, however some strategies you use in mocking, and approaches where as you use it you realize that more complex object it is, harder it is to mock it.  All of the ADO.NET belongs to that category.  You do not mock things such as DataReaders, Linq DataContexts – you create wrappers with really simple interfaces around them.  I have few examples on my blog where I show how to Mock few DAL dependencies.  Posts are old, but they might give you some ideas.

http://www.nermins.net

Nermin

Normal 0 false false false MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

Yes you are right i made a typo there... I was referring to BDD.

I also i think your right about this being very interesting to many CSLA developers and I think that the framework facilitates the concept of BDD very well, hence why i am really looking into this space at the moment (even though it would seem as if BDD has lost a little momentum over the last 6-12 mths). From everything that I have been looking into BDD certainly puts the focus where i believe it should be (i.e. on the behaviour and functionality) rather than the code its self.

The reason for the post though was to see if anyone it doing BDD or TDD and how they go about doing it in a CSLA setting? What do you try to mock out? How do you test your data access methods since they are private methods? etc, etc

Cheers
Anthony

That is the beauty of Csla – you have a choice of putting a DAL code directly inside DataPortal_XYZ or extract DAL into a formal layer / separate set of classes.  There are examples of this in Deep Data sample project that can be downloaded from Lhotka.ne:

http://www.lhotka.net/Article.aspx?area=4&id=7fbb619a-ba81-4157-b434-8756b68ccbd0

If you are using Linq in your DAL, then I would recommend Repository Pattern as implemented by Rob Connery in MVC Storefront sample (it makes both automated Unit and Integration tests a breeze.  Just keep in mind that since that example does not use csla he separates Business Layer objects into Service and Entity objects – Csla objects act as both Service and Entity objects in that example):

http://blog.wekeroad.com/mvc-storefront/asp-net-mvc-mvc-storefront-part-2/

Nermin

Thanks for the reply,

Humm when you say "Have your DataPortal_XYZ methods call your DAL", maybe i have missed something really big here, but I thought that a big part of CSLA, was that the DataPortal methods are your DAL... As in, when you code your DataPortal methods your putting your ADO code (or the wrapper you may have around ADO i.e. safedatareader), directly in these methods. From the sounds of what you have said here it sounds like you are saying that this is not the case.

I know why you are suggesting that you have a "formal data access layer" in this case, but i thought that the point that you have been making with parts of CSLA, here when you were making these kinds of posts and feedback (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3264097&SiteID=1) and in your book was, that if you use a separate DAL you end up with the problem of how do you put data into you private fields (see points "So then how do you load the object???s fields") and that if you have a separate DAL you defeated the point of encapsulation....

Now what i would like to do is be able to test my data access methods independently and mock them but if i don't have a physically separate data access class (for the reasons you have mentioned) and do it with the way that CSLA would normally handle the DAL, how would I do my testing?

Thanks

Anthony

It is certainly true that a separate DAL forces you to deal with the issue of getting data into/out of your business object. But there are decent solutions to that, as noted in the MSDN forum post you reference, and posts here and on my blog.

The ProjectTracker 3.5 code actually uses LINQ to SQL as a formal DAL, using the DTO method of getting data in/out of the business object.

You can also look at the DeepData sample (available in my subversion repository) to see more variations, ranging from the fast DataReader approach through to using DTOs.

It is absolutely NOT the goal of CSLA to tell you how to access your data, or to force you to write the data access code in the DataPortal_XYZ methods. While it is simplest and fastest to write the code directly in the DP_XYZ methods, that approach does have drawbacks.

Architecture is always about making trade-offs. Making the hard choices that pit performance against maintainability against scalability against testability.

Sometimes you have to lose some simplicity or performance to get testability. That’s just reality, and you need to decide, for your application, whether you need testability or performance or simplicity most – what is most important to your particular scenario. That’s why it is both fun and hard to be an architect.

Rocky

I think from a BDD perspective (and I’m not an expert on the TDD/BDD thing), you’d want to have a mock DAL so you can have repeatable tests against your business objects. I doubt BDD itself would test the DAL. Your other alternative is to use a real test database and have some way be which it can be restored to the same initial state before each test (or test run). I honestly think it is often cheaper to create the real test database than it is to mock the entire DAL, but you’ll have to evaluate which makes the most sense for you.

TDD would test the DAL. TDD wants to test everything at a unit level, which is a fine thing (though expensive). So TDD would certainly want you to have unit tests for all your DAL methods. And testing a DAL really does mean having a test database – or mocking your data access technology (ADO.NET, LINQ to SQL, EF, etc). While mocking low-level ADO.NET is somewhat practical, I’m a bit skeptical about the practicality of mocking all of ADO.NET, much less the Entity Framework, etc. So I really think using a test database initialized to a known start point is the best way to unit test a DAL.

Rocky

lol i get what your saying now... I will have to have a look into the DeepData sample and see what the implementation is like. And i would also agree that these issues are what makes architecture and design fun. I guess the light bulb moment for me here is realising that there is not one right way (not that I ever really did) but realising as you said its a trade off between whats important.

So getting back to BDD... BDD says that i should write tests to match business functionality, if i split out the Business and Data Layers, BDD would say (I think) that the functionality tests go against the business layer (because the business layer is what provides the business value) how do i conceptually go about doing the same for the data layer?

Also typemock was mentioned before, I have been looking into to it a bit lately and to really use it to aid in TDD/BDD do i need the paid version or do people find that the free one mtches the majority of cases? I know what the feature set says is different but how often do people find they use the additional features.

Cheers
Anthony