I am wondering what is the best way of testing webapp deployed on Websphere 7. If I consider, that Websphere 7 has no embedded container like for example Glassfish, I don't know, how should I effectively test the app. I mean especially cases, when I need to test data access layer with hibernate, which I usually have on separate EJB.
In other cases I use basic JUnit tests and if I need to set some attributes (like other EJB), I use reflection, but configuring EJB bean to be able to use Hibernate throw reflection seems to be difficult.
Has anybody some experience or could recommend some tools? Thanks.
Your best option might be in-container testing, perhaps using something like Arquillian.
If you would rather have self-contained unit tests, your best option is probably public methods for resource injection (e.g., #Resource public void setEntityManager(EntityManager em)) rather than private fields, which would require reflection as you say.
Related
I am wondering what is the best way to use services in controllers in Symfony 4+.
A controller inheriting from AbstractController can access the ->container->get("service_name") function to retrieve the needed service.
The second possibility is to inject the needed services directly into the controller through the services.yml file. The autowiring feature will easily give the service to the controller's constructor without any extra configuration.
Both approaches seem to work well, what is the cleanest way ?
Dependency injection gives you type-hinted dependencies, which is significantly better than fetching services from container with alias strings. Type-hinting allows you to discover bugs a lot earlier than you would otherwise.
Since php is moving towards being more type-hinted programming language (PHP 7.4 - Typed properties) it is clear that dependency injection is a way to go.
I prefer to keep my handlers free from ASP.NET infrastructure that is very hard to test (yes, even in ASP.NET Core). But sometimes it happens and you have a dependency like UserManager (I'd like to know one day why it's not an interface), HttpContext, etc. and unit-tests are turned into a mocking-hell.
I tried using integration testing to deal with it by creating a TestServer and having all the ASP.NET infrastructure initialized for every api call. It works quite well but sometimes seems like an overkill if I want to test simple logic of my handler. And while it solves technical problem of mocking ASP.NET infrastructure, it keeps architectural problem (if you consider it so) of having ASP.NET infrastructure into your handlers.
I'd like to know what are the recommended approaches to deal with it?
I feel your pain. I stumbled across a fantastic blog post from Jimmy Bogard that handles this problem by using what Martin Fowler calls Subcutaneous Tests. I will leave the deep explanation to those experts but in a nutshell subcutaneous tests simply avoid all the difficult to test aspects of the UI.
Shameless plug: I am currently in the process of writing up a wiki that demonstrates these patterns in a sample end-to-end project on github. It's not difficult to follow but is probably too much code to post for a SO answer.
To Summarize:
If you are using MediatR correctly your controllers should be very thin which makes testing them pointless.
What you want to test are your handlers.
However, you want to test your handlers as part of your real world pipeline.
To Solve:
Wrap the http request in a transaction.
Build a test fixture that mimics the applications Startup.cs
Setup a test db server to execute queries and commands against but also is reset after each test.
That's basically it. Everytime you run an integration test against one of your handlers:
The hosting environment is mocked but your application is started up in a real world test.
Your query or command is wrapped in a transaction mimicking your DbContext.
The handler is executed against a real database and then reset.
I would add more code examples to my answer but between the blog post and the wiki I provided, it is much easier to follow the code examples there.
Edit 8/2021:
Stick with the source. Jimmy Bogard keeps the contoso university project current on his github page. Another great and a little more advanced example is the modular monolith project by Kamil Grzybek. That also is updated regularly on his github page.
Mediatr or no, you should always try to have only very basic pass this along logic in your controllers and call injected business logic classes from there to do the actual work. As you inject them with interfaces to this business logic, your controllers' dependencies are easily mocked in your unit tests, and your tests can focus on if they implement those interfaces properly and do only the basic work of routing input/output. And your actual business logic can be tested even easier.
For those classes that are static, for instance for reading the web.config settings, one strategy that I like a lot is make an interfaced wrapper class around them. While ConfigurationManager is static, I can still just write a regular class with an interface that I put methods or properties on to read a specific setting (preferably semantically named) from the Configuration Manager. Now I can easily mock any configured setting (or absence of it) in my test by just mocking the interface and setting up different return values.
I'd say it depends on the level of confidence you want to get in the end. If you want to make sure the whole system works as expected, then integration tests using a TestServer are probably the way to go.
One advantage of MediatR, though, is it allows you to decouple your business logic from the application using it, which is why at the very top level, let's say in controllers, there's no logic but just a delegation to the mediator.
That being said, you're right that sometimes your logic needs information from the hosting application. An example would be the user making the request, which is accessible in the HTTP context.
In that case, if you want to avoid having to set up a test HTTP server to test your logic works, you could represent that information in an abstraction and your handler would then take a dependency on that abstraction. Your tests could then mock that dependency while using the real system for everything else.
Does that make sense?
I am trying to mock UnityContainer for writing test harness in an asp.net mvc 2 application.
are there any examples available ?
Thanks
Simple Answer: Don't. The container should be invisible to your controllers or anything else you need to test. If it is leaking into your code then you're probably using it incorrectly and should think about redesigning your code.
That said, if you really, really need to then reference the UnityContainerBase abstract class in your code instead of the UnityContainer class itself. You'll still be able to pass in the normal UnityContainer object when your application is running, but you'll also be able to get RhinoMocks to generate a mock of UnityContainerBase to pass in when you are running unit tests.
I would like to implement the MVC pattern to an existing Flex project. I want to separate out the controllers and models from the views. They currently all live together in large mxml files.
My question is, should httpservice requests be in the model or the controller? What sort of advantages/disadvantages would there be to either?
I normally try to abstract any service request into a Command call (execute, result, fault) which gets the service it needs to called injected in (which can be a good idea to abstract even more and be a service delegate).
There's a good example of how to use short lives command objects in Parsley's dev manual (one of the more popular frameworks).
I would rather approach the services as something totally different - an MVCS, not just MVC. You should check the Introduction to Flex Application's Architecture I wrote in my blog.
I looked at httpservice, and it seems to me that, while the service itself might reside in a repository or Service Layer (between the controller and the model), using the service involves references to UI elements such as DataGrid. So the implementation of that service probably would occur in the controller, or even in a ViewModel object.
I'm working on an ASP.Net website along with a supporting Class Library for my Business Logic, Data Access code, etc.
I'm EXTREMELY new and unfamiliar with the Unity Framework and Dependency Injection as a whole. However, I've managed to get it working by following the source code for the ASP.NET 3.5 Portal Starter Kit on codeplex. But herein lies the problem:
The Class Library is setup with Unity and several of my classes have [Dependency] attributes on their properties (I'm exclusively using property setter injections for this). However, the Global.asax is telling Unity how to handle the injections....in the Class Library.
Is this best practice or should the Class Library be handle it's own injections so that I can re-use the library with other websites, webapps or applications? If that is indeed the case, where would the injection code go in this instance?
I'm not sure how clear the question is. Please let me know if I need to explain more.
Though not familiar with Unity (StructureMap user) The final mappings should live in the consuming application. You can have the dll you are using define those mappings, but you also want to be able to override them when needed. Like say you need an instance of IFoo, and you have one mapped in your Class Library, but you've added a new one to use that just lives in the website. Having the mappings defined in the site allows you to keep things loosely coupled, or else why are you using a DI container?
Personally I try and code things to facilitate an IOC container but never will try and force an IOC container into a project.
My solution breakdown goes roughly:
(Each one of these are projects).
Project.Domain
Project.Persistence.Implementation
Project.Services.Implementation
Project.DIInjectionRegistration
Project.ASPNetMVCFrontEnd (I use MVC, but it doesn't matter).
I try to maintain strict boundaries about projects references. The actual frontend project cannot contain any *.Implementation projects directly. (The *.implementation projects contain the actual implementations of the interfaces in domain in this case). So the ASPNetMVCFrontEnd has references to the Domain and the DIInjectionWhatever and to my DI container.
In the Project.DIInjectionWhatever I tie all the pieces together. So this project has all the references to the implementations and to the DI framework. It contains the code that does the registering of components. Autofac lets me breakdown component registration easily, so that's why I took this approach.
In the example here I don't have any references to the container in my implementation projects. There's nothing wrong with it, and if your implementation requires it, then go ahead.