I have two separate projects, one for EF and another for MVC. And added reference of EF project to MVC project.
Now, I am trying to use ELMAH to log errors from MVC application, and it's working fine with MVC exceptions.
But I have one question, if any exception occurs in EF classes then can elmah will log that?
I think, I asked very simple question in curiosity.
I used elmah to log errors from mvc application. My mvc application uses EF as ORM.
To log errors which occurs at EF, I used try-catch, with throw.
Which pass errors to mvc application.
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.
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.
I am trying to start unit testing an MVC2 project, which uses the Entity Framework. When I run my "hello world" test, it fails saying this:
The specified named connection is
either not found in the configuration,
not intended to be used with the
EntityClient provider, or not valid.
How can I pass the connection data (which were generated by the Entity Framework and are in the main Web.config) to the testing project?
Thanks
Depending on what unit testing framework you use you could try adding an app.config to your test-project with the right settings for EF. This works with xUnit.Net and I'm pretty sure most other test-frameworks also support this.
For completeness I do need to warn you that tests that touch the database aren't unit-tests but integration tests. Those are useful too but can become a hassle to maintain when your code changes. It's usually a good idea to test small pieces of code in isolation, this gets around problems like you describe because you won't need to access the database at all.
I would recommended using Dev Magic Fake to Mock the UI without need to use Entity framework or even DB, using Dev Magic Fake, you can run your MVC project and run the unit test without need for any DAL
for more information http://devmagicfake.codeplex.com/
Thanks
I am trying to build a test program in c++ to automate testing for a specific application. The testing will involve sending requests which have a field 'CommandType' and some other fields to a server
The commandType can be 'NEW', 'CHANGE' or 'DELETE'
The tests can be
Send a bunch of random requests with no pattern
Send 100 'NEW' requests, then a huge amount of 'CHANGE' requests followed by 200 'DELETE' requests
Send 'DELETE' requests followed by 'CHANGE' requests
... and so on
How can I design my software (what kind of modules or layers) so that adding any new type of test case is easy and modular?
EDIT: To be more specific, this test will be to only test one specific application that gets requests of the type described above and handles them. This will be a client application that will send the requests to the server.
I would not create your own framework. There are many already written that follow a common pattern and can likely accomodate your needs elegantly.
The xUnit framework in all incarnations I have seen allows you to add new test cases without having to edit the code that runs the tests. For example, CppUnit provides a macro that when added to a test case will auto-register the test case with a global registry (through static initialization I assume). This allows you to add new test cases without cracking open and editing the thing that runs them.
And don't let the "unit" in xUnit and CppUnit make you think it is inappropriate. I've used the xUnit framework for all different kinds of testing.
I would separate out each individual test into it's own procedure or, if it requires code beyond a function or two, it's own source file. Then in my main routine I'd do something like:
void main()
{
run_test_1();
run_test_2();
//...
run_test_N();
}
Alternatively, I'd recommend leveraging the Boost Test Library and following their conventions.
I'm assuming you're not talking about creating unit tests.
IMHO, Your question is too vague to provide useful answers. Is this to test a specific application or are you trying to make something generic enough to test as many different applications as is possible? Where do these applications live? Are they client server apps, web apps, etc.?
If it's more than one application that you want your tool to test, you'll need an architecture that creates a protocol in between the testing tool and the applications such that you can convert the instructions your tool and consumers of your tool can understand, into instructions that the application being tested can understand. I've done similar things in the past but I've only ever had to worry about maybe 5 different "applications" so it was a pretty simple matter of summing up all the unique functionality of the apps and then creating an interfact that supports them all.
I wouldn't presume that NEW, CHANGE, and DELETE would be your only command types either. A lot of testing involves data cleanup, test reporting, etc. And applications all handle this their own special ways.
use C++ unit testing framework , Read this for Detail and examples
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.