I'm not probably first who deals with mocking in windows store application for testing purpose. I would like to test my ViewModels and to use some of mocking frameworks to mock them. Of course, all of available (common) frameworks are not able to use in windows store application project. I have one idea how to solve it but I'm not sure that it is best solution. My solution consists of these projects. Main point is to divide presentation layer to two parts :
Presentation - Windows store application
Start-up project that contains only presentation views (Pages) and presentation parts that do not need to be tested. This project has reference to PresentationLogic.
PresentationLogic - Portable Class Library, Targets : Windows store application, .NET Framework 4.5
This project contains all presentation logic like ViewModels, Converters, Helpers etc. that should be tested
UnitTests - Class library
Classical class library containing unit tests with ability to mocking all interfaces from PresentationLogic. This library has reference to PresentationLogic.
It is quite strange to divide Views and ViewModel to two layers but I did not find another solution for this.
Do you have please any idea how to deal with this problem? What about splitting of the presentation layer to the two layers of another project type? Can it cause some problems in further development?
You're definitely on the right track. A couple of notes:
Using MvvmLight (which is available portable, by the way), you can use their built-in ServiceLocator and DependencyInjection to do things like inject test controllers for platform specific processes. This will allow a ton of your logic to remain portable, by defining interfaces and injecting the implementations (including mocked implementations).
Based on your PCL, you will likely (in my experience) be unable to include Converters (which inherit from IValueConverter) in your PCL. The library is generally different between the platforms (especially Silverlight/WinRT/4.5/Mono), as the most common use for them is for UI, such as binding processing. Same with things like DataTemplateSelectors. These will likely have to be rewritten for most of your platforms (though luckily that's not that hard and is still quite a bit of copy-paste).
As to the rest of it, you have it spot on. You can have your Presentation app be Universal, so it can cover both Windows Store and Windows Phone Store apps. The vast majority of your 'business logic' should be in your PCL. You may run into some issues in this regard because sometimes it's just unavoidable to want to put some UI helpers inside the VM for ease of use. If this is absolutely necessary, you can make your Portable ViewModel abstract, then use the Dependency Injection mentioned above to insert the platform-specific implementations. It's quite easy to do and very useful.
The one thing that you are missing is UI tests. You could include them in your unit test class library, or make another Coded UI Test class library, up to you.
Anyway, hope that helps.
FYI, you can now use JustMock in order to mock directly into Windows 8.1 Unit Test projects.
See my answer
Related
I am dealing with some architectural design concerns that is needed to be sorted out. My current architecture can be seen below. Each box is a project in visual studio, and they together forms solution.
My Core application is coded in WestCore.AppCore Context, and I have another project group called CSBINS (which includes system web service integrations) CSBINS is an merchant product that is why I found it better to seperate it to another project and only depend it with most commonly used interfaces from WestCore.AppCore.
Right now WestCore.Api does not have any logic in it. All the application logic is handled inside AppCore and AppCore.Csbins
The Problem is I sometimes have need to use WestCore.AppCore.Csbins services inside WestCore.AppCore which causes cross referencing issue.
the best approach right now that I think is to add Endpoint Services into WestCore.Api and move cross platform logic to Endpoint Services.
However I would like to get suggestions and design concerns about going further on this since I am very sure that there would be many design choices.
I am also considering to move common AppCore Interfaces and Classes to WestCore.AppCore.Common so that I wont need to reference whole WestCore.AppCore project to WestCore.AppCore.Csbins.
Why are you using services inside other services - this is probably a bad thing and needs refactoring.
Those CORE projects look like are application services projects, it might help calling them 'WestCore.ApplicationServices', Core implies it belongs at the domain level.
It sounds like you need to impliment an anti corruption layer to integrate with the 3rd party vendor rather than creating a whole new 'domain' context. This should be as straightforward as degining an interface in your domain layer (personally I use the *Gateway suffix to identifiy interfaces that interact with external systems)
Not knowing anything about your domain I would probably start with something that looks like this: (I've assumed the csbins is some sort of payment or accounting gateway)
Also, I would strongly recommend avoiding "Common" and "Shared" libraries at the domain level, you shouldn't need them. Your interfaces and classes are DOMAIN objects and belong in your DOMAIN library. The Application Services should be using domain models directly and having implementation of domain interfaces supplied via Dependency Injection. Hopefully your Domain Models are fleshed out enough that your application service classes are just orchestration wrappers.
Starting with ASP.Net 5, I wanted to lay the foundation to my project. As of now, I created 2 projects.
Project - The WebApi project that comes with a Startup class.
Project.Server - A dll project that will hold all the business logic.
At first I though I should write a Bootstrapper class in "Project.Server" that will allow me to hide many parts of that dll (that "Project" doesn't need to know about), but then I found myself thinking I may be doing some extra work; In "Project"'s Startup class I'm calling many of my Bootstrapper class.
Does this extra layer of abstraction needed in a WebApi project?
Although "Project.Server" is currently only referenced in "Project", but I still want to structure is correctly...
Different people will have different opinions on how to structure your web app. Personally, for me, it's a matter of how much work is involved. If it's fairly easy for you to separate out your business logic into a separate DLL, then do it. Even though there may not be any immediate advantages now (since Project is the only consumer of Project.Server), in the future, if you ever decide there needs to be another consumer of the business logic, it will be a lot easier to make that work. However, if it's a lot of work to create this extra layer, then I'd say it's not worth it, since you can't really predict what the future might bring, and so why spend a ton of effort trying to code for a future that is unknown.
There is need to create small scale winform applications for private use by my company for interaction with our database. Period. I know that .NET MVC has a very mature unit testing framework for the MVC pattern as I want to do TDD.
Thus, is it possible to use NUnit or some other easy/mature unit testing framework (EDIT: Based on my experience with ASP.NET) with the following tutorial given here? I have googled and checked my technical book library, and there is a distinct lack of documentation for how to do effective unit testing for winforms. Thus, I am turning to this forum hoping individuals can share their domain knowledge with me.
The most I have found has recommended the MVC pattern (which I agree with), but not how to address specific issues with the winform. For example, how do I test a button click and subsequent action by that button?
I plan on using C# VS13 .NET 4.5. I am excited to join this resource and will contribute rep to all who answer my inquiry. Thanks.
As you have probably noticed, the idea there is to have your view described with an interface.
Thus, the controller doesn't really need a window, it needs a class implementing the interface.
And thus, you could have yet another, auto-mocked or manual implementation of the view interface that doesn't involve the WinForms subsystem but rather, exposes the data to write your assertios.
Having your stub view, you just write a script against it. You expose some methods from the class that allow you to automate the interaction:
public class ViewStub : IView
{
// implement the view interface as it is but also
// an extra stuff to let you automate this in your unit tests
public void RaiseButtonClick()
{
this.controller.DoTheButtonClickStuff();
}
}
Then your test becomes (I follow the convention from the tutorial)
ViewStub form = new ViewStub();
IModel mdl = new IncModel();
IController cnt = new IncController(view,mdl);
form.RaiseButtonClick();
Unit Testing a GUI is something that is independent of the GUI library used. The answer to the general case answers your case as well:
How can I unit test a GUI?
Unit testing a GUI is done by minimizing the footprint of classes that do depend on your GUI framework. Then the classes that still depend on the GUI framework are not unit tested (which is not at all the same as "are not tested"). Those classes are the "View" in patterns like MVP, MVC, MVVM.
Conclusion: Every good .Net Unit Testing framework is a good WinForms Unit Testing framework. One example of such a framework is NUnit, which you mentioned in your question.
Unit testing is not inteded for UI. Of course you can do it, but I don' recommend it for few reasons: You cannot unit test DPI changes, multiple screen, how your program acts in different window states or what happens if user moves with tabulator between your controls. Unit testing UI will only give you false safety.
Use UI automation tools to test UI automatically if you want to, but leave the unit testing out of it. You can keep the UI layer thin as possible and this is also a good design practice. You can use unit testing for other classes which are used in your winforms app.
I have a few questions regarding WPF MVVM application development with PRISM framework:
Should modules in a modular application contain data access code ?
If modules depend on code present in an infrastructure project like the "Stock Trader RI" in the prism documentation does, wouldn't that cause tight coupling between those modules and the infra. project, aren't modules suppose to be self contained functionality !?
I like the DDD (Domain Driven Development) mythology that all code should depend on the business logic layer, thus no "dependency arrows" should go out of the BLL, instead they should go into the BLL (eg. the DAL depends on interfaces in the BLL and then you can use a DI Container to wire everything), and I think that the modules are the BLL of the application, so I don't want them depending on anything, can you achieve that in a modular PRISM app (how) ?
Yes, since a Prism application is usually only made up of modules, then if you want data accessed in your application you will have to access it from the modules in some manner.
Managing dependencies is important. I try to examine what my module does in order to decide whether it makes sense for it to reference my infrastructure project or not. For example, if you were creating an event logging module, you might want to consider putting that interface in a common library that isn't your infrastructure project, because you may re-use that for other projects. However, I do not mind my project specific modules referencing the infrastructure project. The modules still allow me to enforce loose coupling, swap out modules at will to add or remove features, or swap the UI if I were to slice the application horizontally instead of vertically.
I'm not quite sure what you mean by not depending on "anything". I imagine they still depend on the .NET core libraries. So what about Prism? Is that allowed? If you are concerned about them referencing Prism or your infrastructure project you could always have your BLL code in separate DLLS that your modules reference and implement the model repositories, view model logic, and view logic inside of.
I have a large .NET web application. The system has projects for different intentions (e.g. CMS, Forum, eCommerce), and I have noticed a (naive) pattern of calling on another project's class. For example, the ecommerce module needs functionality to generate a file on the fly for products, and I call and reference a method in the CMS to do this, because file handling is really a job for the CMS.
Obviously (and I know why), this is bad design and a case of high coupling.
I know a few ways to handle high coupling, like restructuring the project (although I don't really think this is a robust solution), but what else can I do to reduce high coupling? Any simple tips? Also, it would be good to know why/how they reduce coupling. I use .NET 3.5 and Sql Server 2005 so things like JMS (which I keep coming across in my search for tips on this design issue), are not applicable.
Thanks
BTW,
One of the reasons I ask this is that I have read the previous questions similar to this but usually if a question that has been asked before is asked again, different tips can be learnt as different people reply to the post.
I know of dependency injection/IOC, but I am interested in the small things that can be done to reduce coupling.
How could I choose between using a static class, or an interface-derived class, or the IOC approach when deciding on how to reduce coupling? Also, I could develop a web service which could call a static class - mixing up the approaches in my solution.
The interesting thing is that in my application, I don't want it to be disjointed. So I just have a forum, ecommerce system, and any other module required, but everything has to gel into one site so each module (which is represented as a dedicated project in my Visual Studio solution) needs to know about every other module and work with it. So for example, I might have a module which handles user profiles (working with ASP.NET membership, roles, etc), but this will work with the forum module as a user on the forum will be a registered user on the site (one login throughout), and his or her profile will be coming from the user profile module. This is as opposed to seperate profiles as seen on other sites I've come across).
You should expose web services in those projects who will be needed by other projects. This is kind of the base level idea behind SOA. So, I would just create web services and consume them, which will decouple you quite a bit from how you have it now. Hope this helps.
I'd consider starting by doing an "extract interface" refactoring on the tightly coupled pieces. For example, if using the CMS as a backing store, create an interface that can store things, then create a mediator or adapter class that knows about the CMS, but isolate the logic that knows about the storage mechanism details to just that class.
Then, for testing, you can easily substitute an in-memory store or local-filesystem store that doesn't depend on the CMS being up.
Consider using techniques like dependency injection (See StructureMap, Spring.Net, NInject) to simplify instantiation if a simple factory doesn't give you the flexibility you need.
It sounds like you have a layering problem. Your assemblies should have a single dependency cycle - from least stable to most stable. That allows you to version sensibly. Generally, that cycle would be something like UI (least stable) -> Domain Core (stable) -> Data Access (most stable). You can throw in a Utilities or some infrastructre assemblies along the way, but again - they should be considered more stable than the assemblies dependent on them.
I'd guess your App.ECommerce and App.Cms assemblies are more siblings than layers - so you would not want those to depend on each other, but that doesn't mean you can't reuse functionality. For your particular scenario, you need to push the needed functionality down to a Core or Utilities assembly that both ECommerce and Cms can depend on. If it's a specific implementation that ECommerce provides, then you can push an interface or abstract base class to the Core - and have a higher layer (perhaps IoC container) wire up the concrete Cms.FileCreator class to the ECommerce.IFileCreator dependency.
Get proper abstractions in place as described by others (interfaces, etc). Program against abstractions, not concretions.
Design your classes with Dependency Injection in mind as you have described.
Use an Inversion of Control Container as the mortar between the bricks.
Unity from the Patterns & Practices team complements the Enterprise Library.
Scott Hanselman has a nice List of .NET Inversion of Control Containers.
Well, I don't know anything about .NET, but how about refactoring common code into a separate, underlaying project/layer? Loads of stuff in a web app can be done generically to suit both a CMS, a forum and eCommerce, writing to a file is a perfect example.
Another approach could be to see the forum and eCommerce as modules in a CMS, which would also make sense. Then they could safely use specified API:s of the CMS.