New Posts New Posts RSS Feed: DevForce is NUnit / Moq unfriendly
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

DevForce is NUnit / Moq unfriendly
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
cypher View Drop Down
Newbie
Newbie
Avatar

Joined: 26-Nov-2012
Location: Deutschland
Posts: 20 		Post Options Post Options   Quote cypher Quote  Post ReplyReply Direct Link To This Post Topic: DevForce is NUnit / Moq unfriendly
    Posted: 20-Mar-2013 at 1:30am
We have just started using DevForce / Cocktail for our new Project and we are trying to implement some Unit Tests for Cocktail. 

We are always running into Situations, where we cant access or mock, stub ore fake some DevForce internals. 

For example, we are trying to write a test, how the system behaves, when the user saves 

    [TestMethod]
        public void User_closes_with_changes_and_accept_dialog()
        {
            // create mocks
              var saveResult = new Mock<SaveResult>(); // not mockable due tue internal constructor...

            var unitOfWork = new Mock<IUnitOfWork>();
            unitOfWork.Setup(p => p.CommitAsync()).Returns(Task.FromResult(saveResult)); // no way to mock it

Is there any know way how to mock or stub the SaveResult, to write some tests?
Back to Top
mgood View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 18-Nov-2010
Location: Emeryville, CA
Posts: 583 		Post Options Post Options   Quote mgood Quote  Post ReplyReply Direct Link To This Post Posted: 21-Mar-2013 at 11:25am
cypher,
A mock framework is very rarely necessary to test DevForce/Cocktail applications. DevForce and Cocktail have built in support for faking. The need for a mock framework generally arises if one is faced with code that wasn't written with testing in mind in the first place. Properly written and designed applications don't need a mock framework to be tested. The code would have ample substitution points to fake out implementations for testing. 

As a reference take a look at the unit tests in Cocktail. They use the faking capabilities built into DevForce to test Cocktail functionality.

More on faking can be found here:

http://drc.ideablade.com/devforce-2012/bin/view/Documentation/discovery-compositioncontext-fake

And here you can find information on how to configure Cocktail to use the DevForce fake backing store:

http://drc.ideablade.com/devforce-2012/bin/view/Documentation/cocktail-entitymanager-provider
Back to Top
cypher View Drop Down
Newbie
Newbie
Avatar

Joined: 26-Nov-2012
Location: Deutschland
Posts: 20 		Post Options Post Options   Quote cypher Quote  Post ReplyReply Direct Link To This Post Posted: 22-Mar-2013 at 2:00am
Hi Marcel,

these are very great options for integration tests, but we are trying to achive Test Driven Development with a lot of Unit Tests instead of a Integration Test (with a fake composition resolver).

Using the Fake option is really great, but as per definition of TDD, these are Integration Tests, and we should be able to Mock out the dependencys for a smal unit test, without the overhead of a Fake Composition in place. 

Cocktail is highly testable, but the underlying devforce components dont use interfaces or virtual propertys and some dont even have a public ctor.

so we are running into problems when mocking depenencys for a Unit test.

It will be highly appreceated, if you could introduce some interfaces in the underlying devforce components, to allow better testability for TDD. 
Back to Top
mgood View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 18-Nov-2010
Location: Emeryville, CA
Posts: 583 		Post Options Post Options   Quote mgood Quote  Post ReplyReply Direct Link To This Post Posted: 22-Mar-2013 at 8:59am
I admit, the SaveResult is a bit annoying. I was actually debating whether to expose it through the unit of work. In retrospect I should have not done it. 

You can hide the underlying CommitAsync behind your own interface that doesn't return Task<SaveResult> and instead returns your own result object. Then you can mock it. During integration test you can test the actual save using the fake store. 

In most other cases you can fake repositories etc. and simply return test entities that you new up or use a disconnected EntityManager with its cache populated with test entities, so you can run queries against the cache. 
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down