I am currently working on a Service Fabric project, where in one of our reliable actors we make calls to a SOAP service. For these calls we read a couple of parameters from the Actor's Settings.xml and also - the SOAP endpoint address and binding information from the App.config file (actually the latter is done implicitly by the generated service proxy class for the SOAP service).
Now I am trying to get the unit testing work with xUnit + ServiceFabric.Mocks. To test an Actor specific method I go through:
1) Creating a "MockCodePackageActivationContext"
2) Creating a "StatefulServiceContext" using the instance of the activation context in step 1.
3) Instantiate the Actor with the code below
MyActor target = new MyActor(
new ActorService(
context: serviceContext,
actorTypeInfo: ActorTypeInformation.Get(typeof(MyActor)),
stateManagerFactory: (actorBase, stateProvider) => new MockActorStateManager()
),
new ActorId(Guid.NewGuid())
);
4) I call target.MyMethod() which breaks due to inability to read config info either from the Settings.xml or the App.config file
I made a test where target.MyMethod_Test() does not read anything from config and it was successful.
Anyone who stumbled upon similar thing? How did you solve it?
You could create a separate class that provides configuration data. Create an interface for it and then inject it in the Actor constructor, in Program Main. (Passing the service context into the new class for example.)
Also create a mock implementation of the interface and pass that one to the Actor for testing purposes.
Related
Hello every one I am trying my hands on camunda and would like to say so far the tool seems awesome, but one thing I can't figure out is what shall happen when I bootstrap a process engine (with the same name) across multiple different applications. such as imagine this code is written in many applications but the camunda database url is same in processes.xml which basically means same processes.xml is read for each process application.
// instantiate the process application
MyProcessApplication processApplication = new MyProcessApplication();
// deploy the process application
processApplication.deploy();
// interact with the process engine
ProcessEngine processEngine = BpmPlatform.getDefaultProcessEngine();
processEngine.getRuntimeService().startProcessInstanceByKey(...);
// undeploy the process application
processApplication.undeploy();
Where the class MyProcessApplication could look like this:
#ProcessApplication(
name="my-app",
deploymentDescriptors={"path/to/my/processes.xml"}
)
public class MyProcessApplication extends EmbeddedProcessApplication {
}
now if I instantiate a process instance via the repository service in one application will I be able to reference it another application if I query for it via the repository service? cause I think repository service is accessed via ProcessEngine and surely the process engine object in another application is different from the one that started the process instance? right? but the database is shared so will process instance be available? need help as I cant get my head around this may be i am missing some fundamental knowledge so please do enlighten me.
I have an Azure Function which is triggered by an Azure Service Bus Queue.
The function is below.
How this Run method can be unit tested?
And how an integration test can be done by starting with AddContact trigger, checking the logic in the method and the data being sent to a blob using the output binding?
public static class AddContactFunction
{
[FunctionName("AddContactFunction")]
public static void Run([ServiceBusTrigger("AddContact", Connection = "AddContactFunctionConnectionString")]string myQueueItem, ILogger log)
{
log.LogInformation($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
}
}
I had the exact same doubts.
Adding Unit Tests is not too complicated, at the end of the day, its a function, so all we got to do is to call the Azure Function with the correct string, for parameter string myQueueItem.
Adding Integration tests needs some additional ground work. In the Github project, the author uses the TestFunctionHost class from Azure/azure-functions-host project.
I tried following this strategy, but the amount of code needed to setup all these is uncomfortably high for my liking. Not a lot of it is well documented, and some of the stuff needs developers to use Azure App Services myGet feed.
I wanted a simpler approach, and thankfully I found one.
Azure Functions is built on top of the Azure WebJobs SDK package, and leverages its JobHost class to run. So in our integration tests, all we need to do, is to setup this Host, and tell it where to look for the Azure Functions to load and run.
IHost host = new HostBuilder()
.ConfigureWebJobs()
.ConfigureDefaultTestHost<CLASS_CONTAINING_THE_AZURE_FUNCTIONS>(webjobsBuilder => {
webjobsBuilder.AddAzureStorage();
webjobsBuilder.AddServiceBus();
})
.ConfigureServices(services => {
services.AddSingleton<INameResolver>(resolver);
})
.Build();
using (host) {
await host.StartAsync();
// ..
}
...
Once this is done, we can send messages to ServiceBus and our Azure Functions will get triggered. Once can even set breakpoints in the Functions getting tested and debug issues!
I have blogged about the whole process here and I have also created a github repository at this link, to showcase test driven development with Azure Functions.
How this Run method can be unit tested?
The method is a static public method. You can unit test it by invoking the static method AddContactFunction.Run(/* parameters /*); You will not need a Service Bus namespace or a message for that matter as your function expects to receive a string from the SDK. Which you can provide and verify the logic works as expected.
And how an integration test can be done by starting with AddContact trigger, checking the logic in the method and the data being sent to a blob using the output binding?
This would be a much more sophisticated scenario. This would require to run Functions runtime and generate a real Service Bus message to trigger the functions as well as validate that the blob was written. There's no integration/end-to-end testing framework that is shipped with Functions and you'd need to come up with something custom. Azure Functions Core Tools could be helpful to achieve that.
I have one SoapUI Mock service (served as http://localhost:8454/MyMock) with several operations MockOpA, MockOpB, MockOpC... each of them with his particular unic response.
Is there a way to invoke a particular operation adding it to the URL I used inside the Java code that calls the Mock Service?
Something like http://localhost:8454/MyMock/MockOpA.
I see a lot of examples of one operation several responses; but none of several operations exposed by the same Mock Service.
I have found what I need .....
I am currently working on a project that uses JAX-WS webservices in Java.
The global topic is this : the user creates locally an object, let's say an Agent. He calls a first webservice and passes its Agent to the webservice. The webservice treats the Agent (modifies its properties : e.g. lifepoints), and passes it to another webservice. This call is made from the first webservice, so the user has nothing to do in the process.
After a chain of several webservices, the user retrieves the Agent that has been modified.
The aim of my project is to design 2 parts:
a framework that specifies the behaviour previously described : webservices, Agents and the process of migration
a demo application using my framework. The main difference is the addition of a GUI and a new class Avatar, that extends Agent. So the migration process is still being done "by the framework", with Agent objects.
The following code shows a simple example of how I call my webservice, host my Avatar, then retrieves the agent from the service :
// connection to the server
URL endpoint= new URL("http://SERVER/tomcat/KiwiBidonDynamique/ServiceWebBidonDeDadou?wsdl");
QName serviceName=new QName("http://avatar/","ServeurKiwiBidonService");
Service service = Service.create(endpoint, serviceName);
WebService port = service.getPort(WebService.class);
Avatar myAvatar = new Avatar(1, "Jack the Ripper");
port.hostAgent(myAvatar);
// some process on the service...
Avatar myAvatarTransformed = (Avatar) port.getAgent("AgentNumberOne");
When I do that, I get an exception on the final line :
Exception in thread "main" java.lang.ClassCastException: agent.Agent cannot be cast to avatar.Avatar
After a lot of log reading, I guess the reason is the way the webservice works. When being called, my Avatar given in parameter is marshalled in my JVM then unmarshalled on the service, but the service only constructs an Agent when it unmarshalles. Doing so, it truncates the data specific to the Avatar. Then when I try to retrieve my Agent from the service, it cannot be cast to an Avatar.
Is there a way to keep the Avatar information while processing as an Agent on the service ?
Can I write my own marshalling/unmarshalling somehow ?
Thanks a lot.
If your webservice has Agent element defined as incoming data, then no it is not possible to unmarshall it into an inherited class. I guess it would be possible to write your own marshaller but it is not as easy as it sounds (I would advise against it). Either write a separate WS for each class (messy) or make the incoming data have an element that can store additional structures, like type:any (also messy). The truth is WS are not exactly OO.
I had originally thought that a particular "service interface" and in my example one that inherits from ServiceStack.ServiceInterface.Service is recreated with every request. I recently found out that perhaps it's not the case, as dependencies( and members in general) are retaining internal state. I was just hoping if someone could point me in the right direction as to expected behavior and why it behaves this way. I'm primarily interested in two scenarios, one for IIS hosting, and one for VS hosting / debugging.
A Service in ServiceStack is registered and autowired like any other IOC dependency. Every request a new instance of the Service is created and autowired with its dependencies.
Whether the service is autowired with existing instances or not depends on how the dependency is registered, e.g if you use the built-in Funq IOC:
By default dependencies are registered with Singleton scope, i.e. it will inject the same instance everytime:
container.Register<IFoo>(c => new Foo());
container.Register<IFoo>(c => new Foo()).ReusedWithin(ReuseScope.Container);
You can also specify RequestScope so a new instance is created and injected per request:
container.Register<IFoo>(c => new Foo()).ReusedWithin(ReuseScope.Request);
Finally there's transient scope where a new instance is created and injected each time:
container.Register<IFoo>(c => new Foo()).ReusedWithin(ReuseScope.None);
To re-cap a new instance of your service is indeed created per request, but whether you get a new instance or not depends on the Registration scope of your dependencies:
public class MyService : Service {
public IFoo Foo { get; set; } // auto-wired using above registration rules
}