Finding really hard to unittest with EF4.Must be lack of knowledge on my part.
I am doing some auditing using EF and I would like to test that a particular method on my AuditClass has been called when calling CustomerSave.
How would you approach this?
Can it be done?
thanks
Really i have no unit testing knowledge but i can guide you to this video from julie lerman where you can get some ideas creating a fake context for testing purposes. This requires extra work but its a solution for your problem.
Hope i helped, dont forget mark as answer :)
Related
I've been seeing a lot of articles and references about how to use this patterns for my first (please keep this in mind) serious project with ASP.NET MVC 3 and EF.
The project is not so big (13 tables) and it's basically a CRUD maintenance: organisations that have some users; users that can belong to a group and can create some work areas and templates... Nothing complicated. The point is that this will be the first of a project series and I'd like to create a base to work with.
My questions are:
Which of the previous patterns is the best? Does it depend of the project size?
My models would be these:
Unit of work
Dependency Injection
Do you think they are good enough and appropriate for my project?
I appreciate all your comments.
Serious application doesn't mean to be complex at first sight.
Over engineering an application upfront can be a real disaster, especially if you don't grasp all the technologies involved.
My advice would be to keep it simple. Create a basic application that fulfill requirements (get the thing done and make your boss happy) and then add new concepts along your learning path.
That doesn't mean I promote bad code, no way! Keep your code clean, well organized, etc. But don't be killed by the fear of doing something wrong.
It's normal for a developer to look back to an application made a few weeks ago and then realize that he did some shitty stuff. That's how we progress!
Last but not least, have FUN!
ASP.NET website provides usefull resources to learn the framework and all related guidances. There are a few application samples created step-by-step.
ASP.NET MVC was built with Dependency Injection in mind.
If you want to give a chance to your code to be loosely coupled and easier to change in the future you have to follow the patterns like Dependency Injection, Repository (for presistance abstraction), and UoW (for transaction abstraction).
So my answer is, you should learn about them in the first place to decide after if you want or no to follow the best practices. Even for simple project it's good to apply these patterns because often it gets bigger and bigger. and it's easy to do it in MVC so why to avoid it ?
There is many resources around to learn about. You can just google it.
I would like to answer this question in more generic way. Creating something which can be used in future is difficult than what it seems. All the pattern above can provide you infrastructure pieces to come up with some base framework.
But I would strongly suggest you to look at S.O.L.I.D principals (DI being part of it) to understand some qualities of good code. These are applicable irrespective of the technology involved.
You cannot predict the future requirement of a product\framework, but following these principle you can be better prepare to handle any future modification to the software
You might want to check out S#arp Lite which has many good examples of how to implement the things you want and can serve as a very good base on which to build something quickly.
None of the mentioned patterns are mutually exclusive. You should use the patterns that make sense based on what you are trying to accomplish, not attempt to shoehorn your application design into someone elses idea of how it should work. Sometimes trying to bend your scenario to fit a particular design pattern / practice is the worst thing you can do.
Want to make sure good unit test coverage / do TDD / ensure loose coupling? Then Dependency injection is your friend, as is the Unit of Work pattern. This is definitely a good idea for creating a maintainable, scalable application, but you can go too far with it for a small-scale application.
Need a centralized caching strategy for your data source? Then use the repository pattern. Or an ORM like NHibernate, which might do it for you.
I would like to have a simple sample NH project that you would consider best practice that people could refer to when getting started with NH?
I've been using it for a couple of months now and still struggle with the numerous ways there are to do things but not knowing which is the best approach to follow.
I think one of the best samples is sharp architecture. You can find Northwind example there.
Also you can look at Best practices on code project
uNhAddIns also contains some excellent samples.
Effectus is also interesting.
Still, I'll have to agree with Darin Dimitrov. There's no such things as "best" practices; there are many ways to do things and each one has its pros and cons.
Personally, I learned quite a bit from the WhoCanHelpMe application, which provides a nice reference implementation of the S#arp Architecture framework.
In addition to this, a wealth of information can be found on the following blogs which belong to NHibernate contributors:
Ayende
Fabio Maulo
Davy Brion
I think that really depends on what you mean by best approach. You may like watching some dimecasts screencasts on the subject, I have found them very informative. There are also loads of other topics too. Dimecasts.net
http://www.summerofnhibernate.com/ is a great screencast series on NHibernate
Code Camp Server is a nice reference for ASP.NET MVC and NHibernate
http://codecampserver.codeplex.com/
Also, read a book on the subjects. It will help you a long way.
Edit:
You seem to be looking for a general guide, to take you through some concepts of good design etc. Specifically for ASP.NET MVC, I can recommend http://jeffreypalermo.com/blog/read-all-of-asp-net-mvc-2-in-action-now-while-you-wait-for-the-printed-book/
You mention Onion architecture, the book was written by Jeffrey Palermo, who (AFAIK) invented the term.
If you'd like more sample projects (there are lots and lots) of ASP.NET MVC (with or without NH), let me know.
I’m new to asp.net and the mvc framework and I’m trying to learn by using the asp.net learn tutorials for Building a Contact Management Application in vb (http://www.asp.net/learn/mvc/tutorial-29-vb.aspx).
The question I have is that I would like to begin a new project to start using mvc, but how do I start….
The tutorials start by putting data access and logic into controllers at first and then making the application loosely coupled by refactoring the code.
Is this the way to approach a new project or should I be making the application loosely coupled from the start?
I have followed the next iterations of the tutorials about TDD but couldn’t get my head around that just yet and wanted to really focus on cementing what I’ve picked up so far.
Any help or advice would be great.
I would probably check out the NerdDinner sample app and eBook. It provides some pretty good direction on the best way to do things. Link Here
Id recommend jumping straight into the sharp architecture stuff.
http://www.sharparchitecture.net/
Rob Conery has a good series of walkthroughs in regards to creating an asp.net mvc storefront application. I think they include TD stuff, but are done in C#. Here is the link.
I don't mean to scare you but I wasn't really productive until my 4th project.
Sure, I managed to hack out a few sites but if anyone looked at the code I wouldn't own up to it! :)
Nerd Dinner is certainly the place to start. I also found this site to be one of the most useful.
The trick I found was to, once Nerd Dinner was out the way, pick a pet project and get into it. Then, I picked another pet project and corrected the mistakes I made in the previous one. The 4th project actually resembled a well written site.
It's just because the paradigm for writing sites in mvc is so different that there is a pretty big learning curve. At least that's been our experiance here.
I also recommend S#arp all the time. I was novice to IoC, NHibernate, and MVC when I started, and S#arp was a big help. As for VB, S#arp can be used as binary assemblies; however this surely won't be as easy.
For VB/C# look here: https://stackoverflow.com/questions/1653895/should-i-learn-vb-net-or-c. I personally rarely answer VB questions, and I find C# lambda very helpful, so I can confirm many points there.
But if you only need to learn MVC, not to start real project, NerdDinner will do. Just don't take it as real-world best practices; it's to teach MVC stuff/features, not how to write well-designed and maintenable programs.
I'm trying to find some best-practice examples (or any examples, actually) of using Machine.Specifications with the ASP.Net Entity Framework in an MVC project.
Not having had much experience with Machine.Specifications, I'm keen to see what sort of tests other people find useful and whether there are any gotchas for using the EF-generated objects instead of custom-built ones.
Pointers, suggestions and examples much appreciated.
This is the blog post that got me started using machine.spec, http://blog.wekeroad.com/blog/make-bdd-your-bff-2/
Rob, goes through the complete setup, from installation to writing specs. It doesn't use EF, but it should still get you headed in the right direction. I used SubSonic in my learning project.
I admit that I have almost none experience of unittesting. I did a try with DUnit a while ago but gave up because there was so many dependencies between classes in my application.
It is a rather big (about 1.5 million source lines) Delphi application and we are a team that maintain it.
The testing for now is done by one person that use it before release and report bugs. I have also set up some GUI-tests in TestComplete 6, but it often fails because of changes in the application.
Bold for Delphi is used as persistance framework against the database.
We all agree that unittesting is the way to go and we plan to write a new application in DotNet with ECO as persistance framework.
I just don't know where to start with unittesting...
Any good books, URL, best practice etc ?
Well, the challenge in unit testing is not the testing itself, but in writing testable code. If the code was written not thinking about testing, then you'll probably have a really hard time.
Anyway, if you can refactor, do refactor to make it testable. Don't mix object creation with logic whenever possible (I don't know delphi, but there might be some dependency injection framework to help in this).
This blog has lots of good insight about testing. Check this article for instance (my first suggestion was based on it).
As for a suggestion, try testing the leaf nodes of your code first, those classes that don't depend on others. They should be easier to test, as they don't require mocks.
Writing unit tests for legacy code usually requires a lot of refactoring.
Excellent book that covers this is Michael Feather's "Working Effectively with Legacy Code"
One additional suggestion: use a unit test coverage tool to indicate your progress in this work. I'm not sure about what the good coverage tools for Delphi code are though. I guess this would be a different question/topic.
Working Effectively with Legacy Code
One of the more popular approaches is to write the unit-tests as you modify the code. All new codes gets unit tests, and for any code you modify you first write its test, verify it, modify it, re-verify it, and then write/fix any tests that you need due to your modifications.
One of the big advantages of having good unit test coverage is being able to verify that the changes you make don't inadvertently break something else. This approach allows you to do that, while focusing your efforts on your immediate needs.
The alternate approach I've employed is to develop my unit tests via Co-Ops :)
When you work with legacy code, mock objetcs are really usefull to build unit tests.
Take a look at this question regarding Delphi and mocks: What is your favorite Delphi mocking library?
For .Net unittesting read this : "The Art of Unit Testing: with Examples in .NET"
About best pratices :
What you said is right : Sometimes, it's difficult to write unit tests because of the dependancy between classes...
So write unit tests just after or just before ;-) the implementation of the classes. Like this, if you have some difficulties to write the tests, maybe it means you have a design problem !