This is the 2nd part of another question Entity Framework 4 CTP 4 / CTP 5 Generic Repository Pattern and Unit Testable), where I asked how to implement a generic repository pattern using EF 4 POCO. Now that my repository is working, I would like to know how to unit test my Repository (TDD or BDD).
Thanks all.
Hey I wrote some blog posts on doing this with SpecFlow. But that was a disaster when it got complex.
I tried to implement a testing repository which was also a disaster. Trying to replicate how the data context work is not a smart idea.
But you learn from your mistakes and have fun along the way. What I learnt was to use a light-weight or in-memory database (SQLite).
So I would definitely say to use a SQLite database if you can get it working with EF Code First. I wasn't able to do this, so I went with a SQL CE compact edition. It runs amazingly quick, even in testing.
You probably know all about this blog post, but re-check step 4. http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx
So in essence, all I did on my most recent project was to have a separate database SQL CE 4.0 compact edition for testing. Super quick and no complaints.
Related
So, testing with Sitecore. It's a special topic and I've found allot of reading material regarding it already. (Sitecore Development Chapter 8, Alistair Deneys blog, NextDigital blog, iStern blog,...) but in most of these cases they're going with NUnit and custom test runners etc... The most useful (to me in my context) this far was the iStern blog for mocking out Sitecore using Microsoft Fakes. But is this really the way to go?
I'm surprised that with Hedgehog TDS system to integrate so deeply with TFS and be able to do CI in Sitecore development that there isn't more on how to utilize this system for setting up solid testing executed by TFS (yet).
We're gearing up for a large new project now that uses Sitecore to handle front-end user interaction where the data being used is 95% behind a WCF service. So this part can be easily tested and TDD developed. It's the last 5% (which sadly includes like the highest business value, being online payments) that resides within Sitecore that needs to be tested. Can we ever have enough intimate knowledge of sitecore to mock it out? I'd be inclined to think not... if so, how then do we run conclusive tests on our TFS CI build against sitecore?
Last but not least I get the feeling that the information currently to be found is getting a bit out of date perhaps (maily seeing the remarks on the NextDigital blog), does Sitecore 7 open new ways to tackle this issue?
For those who'd see this more as a philosophical rather then a technical question: There can only be one answer to this and that is a technical accurate definition of a method of using the Microsoft test framework that is capable of running in the TFS CI environment to test code written for Sitecore.
Is Microsoft Fakes the way to go? In my opinion, no. Microsoft fakes allows you to test code that is not designed to be testable. If you design you solution properly, a standard mocking framework should be sufficient.
Can we ever have enough intimate knowledge of sitecore to mock it out? This is kind of a trick question. Unless a third-party library was specifically designed for it and is something that you would consider a "stable dependency", you shouldn't try to mock it. Instead, wrap it with your own classes and abstractions and mock those.
Take a look at Synthesis and Glass Mapper. They are object-mapping frameworks that allow you to map Sitecore items to interfaces while maintaining page editor support. Glass, in particular has a wrapper around Sitecore.Context that can be mocked. Synthesis is supposed to be pretty testable as well, but I haven't tried it yet.
Using one of those mapping frameworks and a good SOLID design, you should be able to make most of your code testable. Just remember that the classes on the edges of your solution should be simple enough to not require testing.
I was in the exact same situation as you, IvanL, a few weeks ago. I wanted to test some of my business logic running against Sitecore 7 without a mocking framework. I managed to do it, but only in a very specific scenario. Unfortunately, I haven't published my prototype solution or the slides explaining it yet, but I'll explain the basics of what I did.
In Sitecore 7, the move towards querying against the index with the Sitecore.ContentSearch namespace and using LINQ opened up a way for me to very easily unit test with fake index data.
There are some unit test examples out there, as you've seen, that use mocking frameworks. However, the classes they mock are actually quite simple to fake out yourself. If you implement ISearchIndex, you really only need to implement the CreateSearchContext method in order to start returning an IQueryable to work with in your tests.
To implement CreateSearchContext, you will likely need to create a fake provider search context implementation that will do the GetQueryable implementation.
Once you have those two classes set up, you've essentially got your 'index' covered. Add a property onto it where you can set the data collection from the unit test and then make sure the context returns that data collection.
That will let you build up a fake index with whatever data POCOs you want, and then pass that through to your standard provider implementations that are running your business data.
The big thing to remember is that this only works for any code you may be writing that will use the new Sitecore 7 way of using LINQ and the IQueryable implementation. Older style code that is running using the Sitecore.Data.Item API still works the way it used to, and has the same limitations as before.
Update: The prototype I mentioned is now available for download: http://blog.nonlinearcreations.com/2014/02/sitecore-7-developers-quest-successful-unit-testing/
NHibernate uses XML files to map the classes to the tables in the database. How can unit testing XML files be easier than program code (C#, JAVA, etc.)? Does NHibernate assume that the mapping XML files are automatically perfect and there is no need to test them?
Fluent NHibernate uses classes instead of XML for mapping and I believe has some support for testing.
Unit test your DAO, which encapsulates your NHibernate queries, to verify that your NHibernate configuration/mappings are correct.
Over the last several years I've taken 3 different approaches:
1 - Don't do any testing. Find out when you deploy to a test server whether the mappings are correct. This is not ideal.
2 - I wrote some code that, using reflection, found all my mapped POCOs and would automatically instantiate them (it was kind of recursive so it'd even explore the foreign keys) then get them back from the DB to see if all the properties were persisting correctly.
3 - Wrote integration tests around my web services. I allowed these tests to exercise the web services code which went all the way to the DB. This turned up any mapping problems.
EDIT - The one other thing I'd mention is that NHibnerate does have a nice feature where you can use an in-memory database. This can be useful for tests where you don't want to mock away NHibnerate but you don't want your tests to depend on a (real) database server.
i am not sure if this can solve your problem or not ... basically if you using nhibernate then you better use fluent nhibernate . which actually builds up proxy classes using POCO instead of hbm.xml mappings which makes your life lot easier for refactoring ..
on your question of unit testing i am myself looking for some clues for unit test scenarios .. say for example if u have a student belongs to department then you actually need to write test cases. You wont be needing any coding for manual testing from deployment. that would solve the problem as of now for manual testing it would be lot more easier cause writing test fixtures makes u test your own code without manual check
here is an example
[TestFixtureSetUp]
public void CanMapCorrectlyStudent()
{
using (ISession session = PersistanceManager.OpenSession())
{
new PersistenceSpecification<Student>(session)
.CheckProperty(c=>c.Studentid,5)
.CheckProperty(c => c.Name, "John")
.CheckProperty(c=>c.Age , 24)
.CheckReference(c=>c.Department,new Department { Dept_id = 1 , Dept_name="MCA" })
.VerifyTheMappings();
}
}
you can find the corresponding example in nhibernate wiki as wel.. install testdriven.net for visual studio , right click on this function body mention above and click run test . it would automatically run the test for you freeing you of all the hassles for manual coding and rechecking the tests
I'm trying to find out how to get csUnit and VS2010/.NET 4 to play nice together. There's no mention of .NET 4 in the csUnit FAQ, which also seems very much out of date. I checked out the Yahoo user group, but can't find any user posts past March 2008 there.
Am I correct in assuming that csUnit is dead? In that case, what test framework have the users moved on to?
In addition to Matthew Vines answer (NUnit and MbUnit), I think xUnit.Net is the 3rd active open source UnitTesting solution.
Consider Moq, Rhino.Mocks and FakeItEasy as active Open Source Mocking frameworks.
I would think that nUnit and MbUnit would be the big ones right now.
But here is a reasonably extensive list of options:
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#.NET_programming_languages
I recently got PHPUnit working with xDebug for testing my Zend Framework applications. The fact I use ZF shouldn't make any difference to this question- just mentioned it for completeness.
Anyway, it all works fine, but now I want to set up an in-memory database using PDO SQLite. I have done this successfully and have created tables and inserted data. However this task seemed to take ages, the syntax from my Export did not match SQLites needs so I had to play around for a while.
Also SQLite does not support constraints (is that right?) which my application does use, so the whole process seems a waste of time if I cannot test my constraints.
Is using SQLite the right solution to my problem? Does anyone have any better ways of using it or any other DB solution to unit testing?
The idea of unit tests is to test smaller parts, so one way could be to work with small amounts of (static) sample data, for example as described in http://www.phpunit.de/manual/3.4/en/database.html
If you really need to test against a full database with all it's constraints, I think there is no way around just using the specific database of your application, for example MySQL.
I've been playing with ADO.NET Entity Framework lately, and I find that it suits my needs for a project I'm developing. I also find cool its non-invasive nature.
After generating a data model from an existing database you are faced with the task of integrating the generated model and your business logic. More specifically, I'm used to integration-test my classes that interact with the data store via mocks/stubs of the DAL interfaces. The problem is that you cannot do this using the ADO.NET Entity Framework because the entities it generates are simple classes with no interface.
The question is: how do I apply a TDD approach to the development of an application that uses ADO.NET Entity Framework? Is this even possible or should I migrate to another DAL-generation toolset?
One of the big critiques against the Entity Framework has been that it is inherently hard to test, for example in the ALT.Net Vote of No Confidence that gef quoted.
Here is a blog post discussing how to get around this, and be able to test your code without hitting the database, when using Entity Framework.
If testability is a big concern, you might want to look at another ORM framework, such as NHibernate, at least until Entity Framework 2.0 is released.
Although, the original question has been answered, I feel like I might add something:
I am currently using the Entity Framework 4.0 on an intranet site I'm building. I am able to test everything in my business logic and controllers without a database connection using the POCO support that has been added.
Although, the POCO's can be generated from the new t4 template included in VS 2010, something that I haven't been able to find in VS 2010 is a t4 template for generating your object context (the object context basically works as a built in unit of work for EF and is essential for mapping your EF objects to POCOs). Luckily Joachim Lykke Andersen in his blog post Entity Framework 4.0 Beta 1 – POCO, ObjectSet, Repository and UnitOfWork wrote a t4 template for generating it and it has been very helpful. If you pursue a solution using the EF4 that is testable without a database connection I highly recommend implementing something similar to his solution which includes a generic repository, unit of work wrapper, and a unit of work factory. It has been very helpful.
Best of luck.
I agree that version 1 of the Entity Framework is a crime against design and it definitely got my vote of no confidence. I credit the EF product team though for acknowledging the failure and responding by opening up their design process to the community. The next release isn't going to be perfect, it might not even be ready for use in a production level application, but I think they're finally starting to understand what's important to those of use who know that bad design is bad business. That being said... I'm still suspicious. Continuous design-time feedback is new to these guys and I've read quite a few statements on the ADO.NET blog that raise bright, red flags. We'll see how it goes with the release of .NET 4.0.
They appear to be trying though:
Test-Driven Development Walkthrough with the Entity Framework 4.0
"The tight coupling of the persistence
infrastructure to the entity classes
largely eliminates the ability to
efficiently use very tight feedback
cycles on the business logic with
automated testing. In its current
state, EF entity classes cannot be
effectively unit tested independently
of the database.
The efficiency of automated unit
testing of behavioral objects is
largely a matter of how easy the
mechanics of test data setup are and
how quickly the tests can be executed.
Using the actual database will make
test data setup more laborious,
introduce data to satisfy relational
constraints that are not germane to
the test, and make test execution an
order of magnitude slower.
A team’s ability to do evolutionary
design and incremental delivery is
damaged by the Entity Framework’s
inattention to fundamental software
design principles like Separation of
Concerns."
Blatantly stolen from here:
http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/
If you're looking specifically at DAL-generation tools you'll have a hard time integrating this with TDD. Most dal generation tools I know also generate your business objects and tightly couple them to the DAL making testing difficult.
You can look at OR-mapping tools like nHibernate and maybe Linq to sql that enable "persistance ignorance", you can define your business objects yourself and they have no links to the DAL or any other infrastructure code. This makes testing your business logic seperately from your database much easier. I found it also enables other scenario's like occasionally connected clients far better.
This answer has changed to "Yes, you can".
You can generate POCO and interfaces using customized T4 templates such as https://entityinterfacegenerator.codeplex.com/, then create mocking objects to test EF in and out without hitting the database.