I'm a grails beginner. and was trying to understand the unit test ..
when i create a domain class Author grails automatically creates a test controller AuthorControllerTests for that domain.
so . in test controller the second line is #Mock(Author)
what does that mean.. what is the advantage i get when i mock a domain class?
as it says in the extensive documentation on testing:
The Mock annotation creates mock version of any collaborators. There is an in-memory implementation of GORM that will simulate most interactions with the GORM API. For those interactions that are not automatically mocked you can use the built in support for defining mocks and stubs programmatically.
Also AuthorControllerTests are the tests for the AuthorController, not the Author domain class.
Just to add something, mocking is useful when you need to isolate a "unit" of code like here your controller.
By isolating, we mean write simple components to replate and simulate all dependancies. This simple components are what we call Mocks.
Grails here gives you the possibility to mock the domain class which will make your tests easier as it won't store the information in the database.
If you want to test the whole stack, from the controller to the database, it's what we call an integration test.
hope it helps
Related
First off, I may be barking up the wrong tree with this, so please correct me if I am wrong.
That said, I am trying to write sme UI unit tests that use WatIn. I am only working on a subset of the UI at present.
I have a controller called Product along with its associated views.
the Controller takes in a ProductRepository via the constructor.
What I would lie to do is to test that different product categories are rendered correctly, in different tests, so I need to pass in some kind of stubbed or mocked repository into my code.
My test is set up along the lines of;
using (var ie = new IE("http://localhost:2904/Product"))
{
...
}
So how do I pass in a repository to my controller that will provide the appropriate product? Once I have called the using statement, my system has launched the browser, so that is too late. But until the browser is launched, then the controller doesnt exist, so I can't inject in the appropriate repository.
Or have I fundamentally got this wrong, and I can only use WatiN against my database, and I need to program it to select a member of each type of product from the db, adn test that way?
I think, as you suggesting, you pick the wrong end of the problem. If I understand correctly, you don't need UI test and Watin but rather integration tests. I would suggest to create instance of controller, inject repositories as needed and mock other dependencies. Than you can switch repositories and so.
In UI tests you test your whole application from the top of UI down to database so it's hard to change behavior or mock some parts. Do you really need to test your functionality with UI? Wouldn't be better to test it only in controller or it's not option for your case?
Seems ok or I misunderstand you completely?
I'll start out by saying I'm a huge fan of unit testing. I've been using it for a couple of years. So far, though, my use has been limited to ensuring engineering calculations are performed correctly, strings are formatted properly, etc. Basically, testing my work on class libraries to be consumed in other projects.
Now, I want to branch out and apply unit testing to my work on ASP.NET Web API. At this point I have my controller written and working with Ninject. Although I'm using Ninject, I'm still not 100% sure why I'm doing it and haven't seen the benefits yet.
On to my question, what are the next steps for unit testing my Web API controllers? What should I do next and when will I reap the benefit of using Ninject?
Next, you could create fake data (or a mock) that your controller can return to your views. This will allow you to do front end development without having to complete the back end implementation.
The benefit of using Ninject is that you can create mock objects for testing purposes. By injecting the interface instead of the concrete implementation you can easily switch between the real and mock object. To do this you simply change which one should be injected in the Ninject bindings. Using something like Rhino Mock in conjunction with Ninject you can write and test your code (controllers, views, etc) without having to fully implement all of the functionality. When you're ready to implement a mocked piece of functionality, you don't have to rewrite your code to accommodate the changes, you simply update your bindings. Now real data will display on your pages instead of the mocked data you created previously.
I am new to specflow and a have a doubt about how to mock my
controller dependencies.
For instance I have a UserController class which depends on my
UserRepository class that a pass to the controller class on its
constructor.
So using Moq I am doing something like this:
var mock = new Mock<UserRepository>();
mock.Setup(m => m.ListAll()).Returns(new List<User>());
var browser = new IE(string.Format("http://localhost:4265/{0}",
username));
But my controller is not using the mocked object, how should I do
that?
Thanks
You are mixing three (atleast) test framework, which ofcourse is cool, but you should probably stop and consider what it is you want to test.
Watin is good for testing your UI as it controls a browser instance. I find it good at making regression tests http://en.wikipedia.org/wiki/Regression_testing
Specflow is great as well - personally i like to use it for closing the gap between business developers and (us) software developers as we can actually define requirements in terms we both understand (and probably other parts of the organization as well) I don't want to start a flame war, but it can introduce more problems than it solves, unless you focus on its real values. We use this at work by testing the service layer (one layer below the controllers in the presentation layer) and we actually only mock the database, external services and file system etc - which makes our specflow tests some kind of integration tests.
Moq is a mocking framework and can ofcourse be used in any kind of tests (like i just let it slip we do) but this is such a great tool for unit testing.
So to return to your question. If you want to make one test to find all your bugs, you're in trouble ;) I know you don't want that - that was just a silly suggestion i made - but really, if you just want to do integration tests (tests running from the UI down through several layers/dependencies) you could easily mix different testing frameworks like you are now, but then why mock the user repository? Is that because you don't want to hit the database?
Anyways one way to do the integration test you seem like you want would be to configure your solution to use a mock - or perhaps a stub would do (create a fake userrepository that returns the data you want to test with) - you should use a Dependency framework like Unity, Ninject or structure map (boy let's not start a war about what framework to use) and have the test url Watin is using launch your site using a configuration with the fake/mock repositories.
You could on the other hand do unit testing on your controllers, services etc. You might even want to try out TDD but that's a whole other chapter i can't cover here!
You are not doing anything with the mock to inject it into your controller. Your controller needs to be given the user repository in order for it to be used.
Also you need to accept more answers.
I have a handful of controllers and each controller has a test class with unit tests. Each unit test calls a single action and verifies that the action handles a given scenario.
The test class has a setup routine that instantiates a number of fake repositories and other fake objects. The fake repositories have static collections that the repository methods/functions operate against.
It is working pretty well but I'm running into some challenges:
When entities in one fake collection reference entities in another fake collection the code in the repository's constructor explodes and becomes difficult to manage
When a unit test calls an action that modifies the fake repository data, the static collection changes state making it nearly impossible to operate against that same data in other unit tests
So I have two questions that might require you to also explain your general approach:
How do you go about setting up a fake collection for an entity that references other fake collections/entities?
Do your fake repositories support update/insert/delete operations? If so, how do you prevent changes from one unit test from impacting another unit test?
As long as your repositories are abstracted with interfaces you could use a mock object framework to generate a fake repository and inject it into the controller being tested. Here are some popular choices:
Rhino Mocks
NSubstitute
Moq
With regards to point 2, why not setup the fake repository in the Setup function on your unit test class (which you do) and use the TearDown to reset the state of the repository after each test.
(These are NUnit specific attributes, so I can't comment if other frameworks have the similar features).
i'm trying to learn how to properly setup testing for an ASP.Net MVC.
and from what i've been reading here and there thus far, the definition of legacy code kind of piques my interests, where it mentions that legacy codes are any codes without unit tests.
so i did my project in a hurry not having the time to properly setup unit tests for the app and i'm still learning how to properly do TDD and unit testing at the same time. then i came upon selenium IDE/RC and was using it to test on the browser end.
it was during that time too that i came upon the concept of integration testing, so from my understanding it seems that unit testing should be done to define the test and basic assumptions of each function, and if the function is dependent on something else, that something else needs to be mocked so that the tests is always singular and can be run fast.
Questions:
so am i right to say that the
project should have started with
unit test with proper mocks using
something like rhino mocks.
then anything else which requires
3rd party dll, database data access
etc to be done via integration
testing using selenium?
because i have a function which
calls a third party dll, i'm not
sure whether to write a unit test in
nunit to just instantiate the object
and pass it some dummy data which
breaks the mocking part to test it
or just cover that part in my
selenium integration testing when i
submit my forms and call the dll.
and for user acceptance tests, is it
safe to say we can just use selenium
again?
Am i missing something or is there a
better way/framework?
i'm trying to put in more tests for regression testing, and to ensure that nothing breaks when we put in new features. i also like the idea of TDD because it helps to better define the function, sort of like a meta documentation.
thanks!!
hope this question isn't too subjective because i need it for my case.
so am i right to say that the project should have started with unit
test with proper mocks using something
like rhino mocks.
The project should have started with a good separation of concerns. Once you have a good separation and you work with abstractions instead of concrete classes using a mocking framework and writing unit tests is a piece of cake.
then anything else which requires 3rd
party dll, database data access etc to
be done via integration testing using
selenium?
Yes.
because i have a function which calls
a third party dll, i'm not sure
whether to write a unit test in nunit
to just instantiate the object and
pass it some dummy data which breaks
the mocking part to test it or just
cover that part in my selenium
integration testing when i submit my
forms and call the dll.
You should not have a function that calls a third party DLL. You should write an abstraction/wrapper around this DLL which you would use and which will be mocked in the unit test where you will verify that your function calls the proper methods without really calling it. You would then use a DI framework in the application to do the plumbing.
and for user acceptance tests, is it
safe to say we can just use selenium
again?
Selenium or any other Web testing framework would be fine. In the more advanced ($) versions of Visual Studio you could write web tests.