Does anyone know if it is possible to test remote procedure calls in Cairngorm Commands with FlexUnit 4. I have an old app full of them and before I introduce FlexUnit into the mix would like to hear if anyone has been successful with this.
Many thanks,
It's pretty easy using asynchronous tests (as you've found the relevant doc) - as long as you can exchange the remote service with a mock service, e.g. by injecting a different service locator that returns mock services, or better by using a DI framework like Spring ActionScript or Parsley. In that case you will have a real unit test that is not depending on a running server.
Related
I have a service composed of several micro services working in workflow. Some of these MS are calling dependencies.
Now I'd like to mock these calls, so when I send a message at the entrance of the workflow the dependencies answers get mocked, but my system works as normal.
The challenge is that I would want to configure the mock from the outside: Configure on the fly the answer I want to get from the mock, run my test, verify that my system behaves properly.
I worked for a company that shall remain unnamed that has an internal tool doing just that, but I'm wondering if there is a public tool doing this? I can't believe it doesn't exist, I bet more on my lack of knowledge about this, at that point ;)
Cheers
So far best I've found is https://wiremock.org/docs/
I don't want to do any ad here, it's just the only one I see that gets its mocks configured from a distance
I try to setup an integration/API test suite with Karate and consider to use Karate Netty for mocking required services. For the test setup the system under test A (a Spring Boot app) is started up completely. The Karate tests are then executed by a Maven test run against this instance.
The service A depends on multiple other services these needs to be mocked away for the tests. To do so my idea was to configure a running Karate Netty standalone instance as HTTP proxy (done by JVM args of the service A).
Now my idea was to create one test feature file: xyz-test.feature
And the required mocks for this file are defined in an associated mock feature file: xyz-mock.feature
(The test scenarios are rather complex and the responses of the external services could vary)
This means for a full test run I need to load up a couple of mock feature files. So:
What is the matching strategy for multiple mock feature files? Which scenario wins, so to say.
Is there any way to ensure, that the right mock file is used for the associated test file?
(Clearly I can reconfigure the running standalone instance and advice it to use xyz-mock.feature next.
But this would stop me from using parallel execution for my API tests, right?)
I already thought about reusing the Correlation-Id which I can send in for each test and then match against this in the mock file (it is also sent to all called services). But:
Is there a way to define a global matcher per mock file?
It sounds like you need only one mock file. You could boot 2 on different ports if you wanted, but there is no way to "merge" them into one port - if that is what you were looking for.
In my experience, you will be able to have a single mock take care of all your edge cases. This is because Karate's approach is un-conventional: you pretty much write a stateful server. But by keeping variables in memory and some clever JSON-path, you can simulate CRUD with very few lines of code: https://github.com/intuit/karate/tree/master/karate-netty#background
You can use only one at a time, by design
Given the above limitation, here's an interesting idea: add something like an extra pathMatches('/__test/reset') scenario that cleans-up your state and sets the Background variables to things like * def cats = []. Now in each feature, just call the special "reset" URL at the start. The good thing is Karate is thread-safe. Another idea as you said is you can maintain two or three different variables and use some logic to "route" based on a header, again very easy IMO. Use a map of maps, e.g:
def data = { cats1: {}, cats2: {}, cats3: {} }
And you can get the header, e.g. if it is mode: cats1
* def mode = karate.get('requestHeaders.mode[0]')
* def cats = data[mode]
not sure if this answers your question, but if the last Scenario has an "empty" description, it is a "catch all" and can in theory delegate to another server (or mock): https://github.com/intuit/karate/tree/develop/karate-netty#proxy-mode
Your question is a little confusing, so you may have to edit and re-word it if I haven't understood.
EDIT: using multiple mock files should be possible in 1.1.0 onwards: https://github.com/intuit/karate/issues/1566
I made some first steps with Arquillian and get it starting and some simple tests like testing DI etc are working. However, I need to test EJBs that are secured (RolesAllowed) adn I didn't find any solution till now. Further, I have a book regarding Testing with Arquillian and WildFly - the topic about security etc is not mentioned at all - not with a single word. I have also another two books regarding Java EE development where testing is also mentioned, however, always without involving security... I don't need any code just few tips what is required in order to get it working...
Thanks in advance for any suggestions/support.
BR,
Erno
You need to test entire request and issue login before request (If you are doing so called client tests. If you are doing this, your IT class would probably have #RunAsClient annotation).
If you don't have #RunAsClient, you can try to mock the session with the desired roles.
Can you have automated regression/integration tests for Azure Logic Apps?
And if you can, how? ... especially in the context of CI/CD builds and deployments
... and if you can't, why not!!
There isn't any out-of-the-box tooling yet to provide automated testing of Azure Logic Apps. We have a few customers who have followed one of the following patterns. There is also this article that goes into detail on how to create a Logic App deployment template:
After deployment (using a release management tool like Visual Studio Release Management), a series of unit tests are run (writtin in something like C#) to test the Logic App.
Since a logic app could have any kind of trigger (on queue item, on HTTP request), the code usually performs the action and asserts the result.
A logic app in the resource group that can run a series of basic tests in a workflow. This one requires a bit more chewing on, but idea being you have a workflow that makes use of connectors or "calling nested apps" to perform basic validation tests (ensure connections are active, etc.)
It's something we have had discussions on from time-to-time, but would love to know if you have any thoughts on what types of tooling/configuration you'd want to configure for an app (remember that some apps "trigger" on something like a message in a queue or a file in FTP).
I would like to share one of the approach for LogicApp testing that my team has followed.
First level of validation is the ARM template deployment status (ProvisioningState) which should not have any errors.
After that we have developed test automation using the logic app sdk which does the following
Get auth token.
Execute a specific logic app trigger with a synthetic transaction.
Waits till the execution is completed.
Gets logic app & its action status (succeed, failed or skipped), validates it as per the expected scenario.
Gets the outputs from each action execution, validates them against an expected scenario.
Repeat above steps for all the various cases that logic app might go through.
Hook this all-in CI/CD :)
Deployed an LA, ran a synthetic transaction & validated the results.
Hope this helps.
I want to write some code using the SAP .Net Connector 3 to receive and send data to a SAP System using RFC and iDoc.
How can I setup a simple SAP Test System with RFC to test my code.
Is there a way to mock the SAP System or do I have to install a SAP System?
If so is there any simple tutorial on how to setup an SAP System with a simple "Hello World" RFC?
I was originally going to post a comment. But it was too long.
This isnt a solution, its a warning.
I think you have placed too much emphasis on unit test for this type of solution. Mock the rest of the code all you like. But mocking an interface that may/will behave differently is false confidence.
By all means abstract the infrastructure layer and push dummy data into int to test the rest of the app. But dont plan on mocking the interface in any way that is relevant to stability.
How do you plan to mock:
The sign on process
single sign on, SNC...
gateway connection
connection specific settings
authorizations
load balancing
connection pooling
timeout
Test it against the DEV system, then test again in QA system
and get ready for unexpected issues in PROD.
You can write code to generate TABLE/STRUCTURE content. So you easily mock what that you expect to receive or send to SAP system. Write a dummy that returns that data and mock the call. Dont bother with mock infrastructure. That achieves nothing.