I have a VS winforms project which has lot of database calls.
Whenever i create unit testing, there is more number of methods, taking more time to consume and more number of unit test projects.
How do i isolate DB calls or will i be able to isolate DB calls if i use microsoft's moles and pex? Any samples on moles and pex will be highly helpful.
You can isolate anything - database calls, web services calls, SharePoint. It does not matter. Your project has references to a number of external dependencies like System.Data. You can either grab the pre-built moles assemblies or build you own. Framework is pretty rough at some points, but it works.
Related
I have a solution with several projects that use .NET Framework 4.7.2. One of the projects contains all of my Entity Framework models and the DbContext (EF v6.4.4). It also uses the ASPNet.Identity.EntityFramework (v2.2.3) extensions.
The projects contains an API layer, common layer (shared DTO models, helper functions, etc), WebJob project, and a Unit Test project.
I need to add in an Azure Function project to process messages from a service bus queue (which receives messages from our ERP system) and update our front facing e-commerce web app.
I need to get with the times and get more familiar with .NET Core / Standard project types. My issue is that the Azure Function project is using .NET 6.0. I want to reference my Entity Framework project.
I have been reading that with later version of .NET Core / Standard, there is "more" compatibility between those and .NET Framework projects.
I was able to reference everything in my Azure Function project and get it to compile with not much issue. However, when I go to do anything with the Entity Framework (read from the DB or write), I get an exception like this:
System.Private.CoreLib: Exception while executing function: InboundFunctions. EntityFramework: The type initializer for 'MethodCallTranslator' threw an exception. System.Private.CoreLib: Value cannot be null. (Parameter 'key').
After digging some more, I seem to have an issue with the Microsoft.AspNet.Identity.EntityFramework package. I had to include this in my AZ function project to satisfy the implementation of the IdentityDbContext. According to VS, this is the library that is throwing a warning about compatibility issues.
At the moment, I am not sure how to resolve this. Would it be easier to make a new DbContext for just the .NET Core stuff or is there a better approach? I don't need any of the Identity stuff in my Azure functions project - it's really only used in my API layer.
Thank you for your help!
I am in the process of Dagger to Hilt migration. There are several useful apis like #OptionalInject, scope #AliasOf, Compiler option to disable #installIn checks etc. to migrate source code from using Android Dagger to Hilt.
Migrating tests seems super tricky. My test infrastructure setup is such that I have a custom ActivityTestRule that helps with creating a new appComponent every time a test is run. So basically I would do something like DaggerMockAppComponent.builder()... in beforeActivityLaunched method of activity rule. With Hilt, seems like HiltAndroidRule tries to do something similar where it provides a new app component for each test case.
Refactoring all the test setup to work with Hilt seems to be a big upfront and time consuming effort and I would like to get the source code migration going without having to redo the whole test infrastructure setup.
My question is would it be possible to continue to run tests using existing setup based on Dagger (i.e. not use #HiltAndroidTest and HintAndroidRule) and in future migrate to use either CustomTestApplication or HiltTestApplication after the source code migration is complete?
I tried to like create a prod application that uses Hilt and a test application that uses android Dagger for app component generation and it seem to work but the issue i see is that if I annotate an activity/fragment with #AndroidEntryPoint, the corresponding tests wouldn't run and I see the following exception:
java.lang.IllegalStateException: The component was not created. Check that you have added the HiltAndroidRule. That makes me wonder if it's even possible to delay test migration until all source code migration is complete.
A broader question would be: what could be a good approach to incremental dagger to hilt test migration?
The visual studio project templates for a Service fabric services contains code that can be reused over other multiple projects. For example the ServiceEventSource.cs or ActorEventSource.cs
My programmer instinct wants to move this code to a shared library, so I don't have duplicate code. But maybe this isn't the way to go with microservices, since you want to have small independent services. Introducing a library will make it more dependent. But they are already dependent on the EventSource class.
My solution will be to move some reusable code to a base class in a shared project and inherit that class in my services. Is this the best approach?
I'm guessing all your services are going to be doing lots of different jobs so once you pad out your EventSource classes they'll be completely different from each other except one method which would be service started?
Like with any logging there is many different approaches, one of the main ones I like is using AOP or interceptor proxies using IoC containers, this will keeps your classes clean but allows re-use of the ETW code and a decent amount of logging to be able to debug later down the line.
I moved a lot of duplicate code to my own nuget libraries which is working quiet well. It is a extra dependency, but always better then duplicate code. Now I'm planning to make my one SF templates in visual studio, so I don't have to remove and adjust some files.
I found a nice library (EventSourceProxy) which helps me managing the EventSource code for ETW: https://github.com/jonwagner/EventSourceProxy
We are working on some spikes using Fuse ESB (Camel,OSGi, blueprint) to deliver some components. We have an imposed architecture from our EAs which is: REST controller uses a route to call a CXF WS. This calls a local java class as a service to, for example, perform CRUD actions. These use JPA enabled DAO/entities. All seems a bit academic in design rather than real world but thats another story.
Question is about testing. Normally I would actually test this service tier using H2 to provide the DB, wiring the DAO, entityManager etc together with spring (I know some wouldn't do this but I do, bear with me). But we will use blueprint for fuse. How can I unit test this tier? Getting my tests to subclass CamelBlueprintTestSupport doesn’t work, this expects a route. Can’t use SpringJUnit4ClassRunner (though do have it working with this currently) as this wires with spring, when running in the container we will wire with blueprint.
So how do we unit test this? How do I instantiate this set of classes within a blueprint based unit test? Can we?
One aproach you may try is to use pax exam. It allows to run tests in a full OSGi environment. So you can install your real bundle test it in a black box fashion.
You can use pojosr which is what camel-test-blueprint is using: https://code.google.com/p/pojosr/
Though pojosr is not a full OSGi environment, so there will be some limitations what you can do.
For the camel-test-blueprint you may be able to override the method isUseRouteBuilder and return false, then it ought not to expect a route.
I have a server-code that's written in Python, and I have a client-code that's written with GWT. Now I want to run automation testing on the GWT against the data from the Python server.
From what I searched, people recommends using the Selenium, but I prefer to have a GWT-test that has more visibility into the client-code. That way I can verify the local database, and any data that are not exposed to the UI.
Also at this point I'm not too worried about the DOM aspect, layout, and the other UI stuff.
Is there anyway to make the GWTTest work with external server?
I've tried to search for the solution, or people with similar problem, but I couldn't find one. If this question has been asked previously, I apologize.
Thanks, KOkon.
You can use the GWTTest framework to incorporate testing some GWT components that call the server. But the tests won't be able to communicate directly with the server. If you need your tests to set up state on the server, I'm afraid you'll need to write special "for testing purposes only" RPC servers or servlets or similar to do it.
Having said that, I would (presumably like those who suggested Selenium) recommend three types of tests:
Unit tests for server components, and unit GWTTests for client components,
Integration tests for testing server code interaction with database, etc.
Selenium acceptance tests, which are "black box" - they don't have access to the innards of the GWT components.
What you could do is create a proxy servlet that gets started in the GWTTestCase embedded Jetty instance. That proxy could forward all calls to you real services in Python.