We are using VS2010 with the 4.0 framework with MS test. So my question is should we create unit tests that call the aspx.cs page? We are using EF 4.0 and the aspx.cs pages call down into our repositories ( Classes that create / setup and remove objects from the context ).
So I know that we need these tests but, should the tests call into the aspx.cs pages or should I separate the calls to the repository into another file that can be tested by is self. I've never tried to do something like:
MyPage1 pg1 = new MyPage1();
// Test methods..
Thanks
No.
Testing aspx pages is hard and horrible. It sounds as your app is highly coupled if you need to test your views in this manner. Test your repository in isolation, you won't be able to test it in the view but keep the logic simple enough and you should be ok. In other words make your pages simply invoke your repository and return the results.
Alternatively check out adopting a MVC paradigm.
Related
Hi one of my client needs unit tested application in asp .net webforms. But I have no Idea about how to start or unit tested applicaton/MVC. I would like to know how to create unit tested application in webforms. Any example, video, tutorial will be helpfull.
Thnaks
I suggest you do the following things:
Start asking your client and yourself what it is you want to achieve? Merely unit testing for no other reason than saying you are unit testing is not a worthy goal to pursue.
Read some introductory book like The Art Of Unit Testing to make yourself familiar with unit testing.
Consider reading this ASP.NET MVC book because it takes you through all layers of an ASP.NET MVC app while applying unit testing at each of those layers (with really good examples).
I agree with point 1 of meilke's answer. Adding unit testing to an existing application can be a lot of work and without a good reason, it's unlikely a customer will want to pay for it. It is possible however to use a request to add or remove functionality as an opportunity to get started. For example, if you have a task to remove some existing functionality then putting a set of unit tests in place to verify the existing behaviour of the application can save headaches later on. Think of it like putting scaffolding in place before doing construction work.
It's not clear from your question but if it's ASP.NET WebForms as distinct from ASP.NET MVC that you are looking to unit test, I would recommend looking into the Model View Presenter design pattern. Here and here are a couple of articles that should help.
I'm working on a project that has client and server side. And I'm writing a "pre-check-in" tool that will validate a lot of our communication between client and server.
I already have unit tests on both sides, now I really want to test the integration between both.
Like a real client connection to the server and vice-versa.
I really want to go unit testing on this, but I'm having a really hard time figuring out how I can initialize the MMVMCross framework and my view model classes.
In another thread I've asked for help on my "console app" that runs the tests but it is also really hard to initialize the framework and it makes me loose the coolness of unit testing with Visual Studio and reSharper.
My view models use SQLite and HttpClient with async/await.
For instance: I can't find a way to instantiate a view model that would need this interfaces:
IChatService, IMvxMessenger, IDataService, ISettingsService
Some from the framework some from my own code.
I known and I'm trying to register my ones, on a TestFixtureSetUp, but off course this fails, as the MVVM base subsystem (ioc?) is not setup yet.
Some above services, like IDataService for instance, also needs ISQLiteConnectionFactory, IMvxMessenger, ISettingsService.
I know unit testing is supposed to be fast, but my idea is to put all this tests in a new Category, that I would run only before my check-ins and my buddy, server developer, would run before his check-ins.
What would be the best approach here?
Any hint, suggestions, things to investigate/study would help at this point, as I'm practically stuck on this one.
Sergio
For instance: I can't find a way to instantiate a view model that would need this interfaces:
IChatService, IMvxMessenger, IDataService, ISettingsService
Generally this would be done using Mock implementations and then calling the ViewModel constructor directly with those Mocks.
I'm having a really hard time figuring out how I can initialize the MMVMCross framework
In order to initialise the IoC part of the framework you can use the MvxIoCSupportingTest helper class -https://github.com/slodge/MvvmCross/blob/v3/Cirrious/Test/Cirrious.MvvmCross.Test.Core/MvxIoCSupportingTest.cs
If you then need additional parts of the framework, then generally you should mock these in some way. For example, see how navigation is mocked in these two articles:
http://blog.fire-development.com/2013/06/29/mvvmcross-enable-unit-testing/
http://slodge.blogspot.co.uk/2013/06/n29-testing-n1-days-of-mvvmcross.html
If it helps, an example of this type of test is https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20TwitterSearch/TwitterSearch.Test/TwitterViewModelTest.cs#L21
If this answer doesn't have sufficient information, please provide a bit more example code about the tests you are trying to write.
How to do TDD/BDD with asp.net 4.0 Web Forms? I have an existing website that has very large scale and we dont have any test with each change in database we have to guess what will break? I want to introduce unit testing please give me pointers?
A lot will depend on how your existing codebase is structured.
It can take a lot of work to retrofit Unit testing and especially TDD into a legacy project. Typically you'll find database and business logic residing in the code behind file of the web pages.
Use of interface types are your friend here as Visual Studio can generate Interface classes automatically for you. (Place the cursor over a class name, right click, select refactor and extract interface)
I would work towards separating your database code into a class library project of it's own. You can then specify the public interface through which the business logic etc can access the database. All other code should treat the database repository as a black box.
Create a factory to make your repository (based on that Interface), have it create a test type and a live type. The live type will link into your current database code. The test type will just return hard coded values. You can write tests using the live database, then you can write tests for the "test" database in a TDD manner.
Once they both match (all tests pass) any new database functionality is added by writing the test that runs on the "test" database first and then on the live database.
Remember all code should only use the Interface to the database not an instantiated live database class.
Once you've got the hang of the process you can delve deeper (if you wish) within the database code, but I would say that following the same process in separating and testing business and UI logic is more practical on a legacy project.
You may find that a pragmatic approach is to only separate out functionality following the process that I've described as you go to add new code. In other words before you add new functionality, separate out the code as described writing the tests that show that it passes (live and test version) then alter or add test for new functionality using whether the test passes or fails to guide your coding.
If covering all bases you want a test for failure, test for pass and maybe a test for exception scenario.
Good luck. It's not a job for the faint hearted (having had to do it many times in the past).
I had to code something in Wicket (or take any MVC framework) that given 2 variables A and B provide the boolean result C which tells if something (a checkbox) is visible or not.
Now this is view logic, but let's say it is not as trivial as like: C = A && B;
Maybe some automated testing is good to have.
Where would you put this logic? Is it okay to put it in the Model/Service layer and test it with JUnit ? In my understanding Model and Services are reserved for business logic.
Or do yo keep it in the View in which case you test it with something like Selenium ?
Or build some static method in some Utility package ?
I would build it as to get the thing done and build a test for it as simple as posible but not to mix it with the services. So i would chose a static utility method.
I use also complex visibility logic in one of my wicket MVC project, and I put this logic into the service layer, and I test this code with JUnit. I also have wickettester test which tests the visibility of the checkbox also. I don't know what the best way is, but think this way is not bad. Hope it helps.
From a tech-agnostic p.o.v. I'd say this sounds like some logic that interacts with the view state. So this logic belongs with the presenter/controller.
Since the presenter/controller is a class - you should be able to test without bringing the view into the mix. I'm going by the MVP or MVVM idea.
It is view logic and as such it should be in the view layer.
Personally I would test this using Selenium. It depends how you are doing the visibility, using the wicket tester may be enough, but all view logic should be tested on real browsers using a tool like Selenium.
You should definitely not use a static utility method, for why see here
I'm just starting my first MVC3 application, and I'm not sure how to unit-test it. I was planning to break out helper classes (static helpers, usually) into a separate assembly, as well as model classes, so that I could test them with NUnit.
So I'm OK on helper classes; but how do I test model classes (considering that they're annotated for NHibernate and tied to the database), and how can I test my views and controllers?
What are the specific tools and techniques I need to test NHibernate-bound models, as well as ASP.NET views and controllers? I'm not sure. NUnit only solves some of the problem.
Edit: Here's some samples of code -- I'm not on my dev machine right now, so I don't have real code to show-case.
Models: Anything from the ActiveRecord documentation
Controllers: The standard HomeController from the MVC3 documentation
Views: Any strongly-typed view (let's say Create) generated from the right-click context menu (Add > View)
Specific questions:
How I can test saving models without actually saving to the main/production database
Scope for testing views; should I simply test fields exist? What about validation error messages?
Controllers: scope for testing. Should I test that actions touch and deform database data as expected (eg. /get/id gets that object; /delete/id deletes that object)?
You can get there by various kinds of tests, but you need to apply them wisely depending on what you are going to test:
Use unit test to test your controllers, or your business logic, without hitting the database.
Use integration testing by running on an in-memory database (which NHibernate supports and is easy to setup). You can make sure a scenario actually works, e.g. using a valid scenario, all the business logic is working, your controller pass the data to persistence mechanism and it goes correctly into the database.
You can use UI Testing using frameworks such as Selenium but only do that where really needed, because it is not easy as two previous types of tests, and would become hard to maintain and fragile.
It is a best practice to keep your view (UI) thin, and test other layers behind the UI, as testing the UI probably does not worth all the hassle.