I am writing tests for an HTTP REST-like API. These tests are end-to-end tests, communicating with running application (web server, database, everything).
I am looking for a good way to test time based features. Since it is end-to-end test, I cannot simply mock time related functions.
As an example think about the google calendar.
Scenario: Event notification
Given it is 15:09
When I create new event starting at 15:20 with email notification 10 minutes in advance
Then I receive email notification within next 3 minutes
For single test I can just create on time and wait for email, but when I have repeated events (say weekly) than I need to test notification comes next week.
I was thinking about sending header that would (in dev environment) change application time, but the worker that sends notifications runs in separate process and would not be affected.
Related
I have an application that mimics an equity market. One part of it, generates price changes and POSTS them to a consumer sending roughly 100 price changes roughly ten times a second. The second part of the market exchange takes in orders, executes them randomly and asynchronously sends execution reports back to the same consumer of the price changes.
I want to put this on a App Service, but here's the issue:
I want the price generator to start immediately and run continuously.
The order execution only needs to run when orders are sent (asynchronously) and all the orders have been executed or cancelled. Then it can shut down until another order is received.
It seems like I'm forced into one of two buckets and neither applies to what I want to do. A Web Job appears to work like a Service in Windows 11. It will start up immediately and run until you shut it down, but it doesn't have the logic to handle an ASP-type controller.
Deploying as an App Service works as long as I wake it up by POSTing an order, but the price feed doesn't start until I send the order.
So here's the question: How do you deploy a .NET Core application as an App Service and have it start automatically (without waking it up with an initial HTTP call)?
According to your description, I suggest you could consider modifying the price feed as a background service inside the .net core application. The background tasks can be implemented as hosted services. A hosted service is a class with background task logic that implements the IHostedService interface.
It contains the StartAsync method. The StartAsync(CancellationToken) contains the logic to start the background task. StartAsync is called before:
The app's request processing pipeline is configured.
The server is started and IApplicationLifetime.ApplicationStarted is triggered.
More details, you could refer to this article.
Besides, I suggest you could also set the Azure web app's configuration as alwayson.
I'm a Newbie in using JMeter tool and could not find a approach in JMeter to run End to end performance test of below use case:-
I have https webhook(Hosted on my node JS server) that is invoked on new device creation on Azure IotHub(Webhook subscription is done on Azure IotHub).
Once invoked, I parse the webhook(request) body and generate a unique token.
Once unique token generated, I set that token in the device configuration for which the webhook was called.(I get the deviceId in webhook body)
Once the device configuration set I return the response of webhook as 200.
Now, In JMeter how can I achieve step 1-4. My initial approach is to:-
Write python script to simulate new device creation on IoT hub.
After step 1 I'm not sure how will I capture the webhook invoked and response returned from webhook in JMeter.
Basically, Im not sure how I can successfully capture Step 2 and 4. Step 3 is basically the nodejs code for my webhook hosted on my server.
And I need to run step 2 and 4 200K times to measure the performance.
In summary, I have a script which registers device on cloud which triggers my webhook/api and I will calculate the response time in my script i.e. everything will be written in my script just that I want JMeter to show all the charts etc. based on the calculations I do in my script.And the script should be invoked n number of times as per the load required.
Any help in guiding me the approach would be very appreciated.
I have a solution for this now, in case anyone needs it.
Thread Group --> OS process sampler --> Response time graph
Above are the components I used in my JMeter tool. OS process sampler can run any script on your machine.
We have an UCWA App that runs as part of a ASP.NET Web Application (as a singleton), and we're using a scheduled job which every two minutes performs reportMyActivity as per documentation; to maintain the application alive and Online.
What we observe, looking at our server logs, is that the application is anyway regularly being shut down by the server, approximately always in about 20 minutes after it was created. During these 20 minutes reportMyActivity returns correctly 204 - NoContent, after that (when going offline), reportMyActivity returns 404 - NotFound instead.
We're also now dumping every event coming through the event channel, and looking at them I don't see any event or evidence being raised; corresponding with the time when UCWA App is being shut down from the server.
We're targeting an on-premises multi-tenant environment.
Any idea or suggestion?
We're trying to write BDD tests using Jasmine, and a common use case we need to handle is:
User A: Does some action
User B: Gets notified after xx ms that the action has happened asynchronously (either via WebPush or polling)
User B: Responds to user A's action
User A: Receives B's response
I'm struggling to build an automated test for this scenario. Our current tool-of-choice is Jasmine, but we're flexible at this point. How can you handle multiple logins simultaneously, especially where there is some delay between responses?
The naive way to do it is to simply poll for each action, and move the scenario on once that action has been detected, with timeouts that fail the test if it takes too long.
In any language which allows for multi-threaded execution, you can create a "Waiter" pattern which waits for the event, then passes execution back to the test once that event has been detected. I've got a C# example here and a Java example here.
Javascript doesn't allow for multi-threaded execution, but it can be faked.
However, I think your biggest problem is that with two logins, you've essentially got two tabs or windows or tabs or apps, and yes, that's going to be hard to manage. You could do it with something that interacts with windows, rather than with the browser (my C# example is from an automation tool that does this), but that would mean adopting a whole different tech stack for the automated scenarios.
You can get around it though by dividing your scenario up into portions:
Given users A and B are running the app
When user A does some action
Then user B should be notified.
For B, use a fake version of the app; stub out everything from the service onwards. You can then check that B is notified via the service's API. You could even just write the things that B receives to a text file, or something similar. It doesn't have to be a real B.
Given users A and B are running the app
When user B receives a notification from user A
Then user B should respond.
Given users A and B are running the app
When user B responds
Then user A should be notified.
For these ones, we're now stubbing out the app for A, notifying as A through the API in the first and verifying notification from B in the 2nd.
Given user A is waiting for user B's response
When A receives user B's response
Then A should (do whatever they would normally do when they receive that response).
And we're back to stubbing out B again, injecting B's response into the API, bringing the journey full-circle.
In each case, we're still verifying that the interaction with the service works; we're just not doing it all at the same time. This should still provide enough confidence that everything is good. It just takes a few more scenarios to do it.
Please do talk to the business about this too and use the language that they use when describing what they do, rather than A and B notifications and responses like I have here.
how to send SMS after 4 days from a Symbian app by running the application in the bachground. Means application sends SMS after 4 days? Is that possible?
Please reply soon.
I don't think you would want to achieve this by running your application in the background for 4 days. For a start, if the phone was rebooted or ran out of battery in that time then the SMS wouldn't get sent when it was switched on again.
Instead, you can use the message centre API to schedule the SMS to be sent at a particular time.
The TMsvEntry class lets you call:
SetScheduled(ETrue);
SetSendingState(KMsvSendStateScheduled);
and then you can set TMsvEntry::iDate which is a TTime to the date/time you want the message to be sent.
This example shows how to send an SMS, try looking at:
void CSmsEngine::SendSmsL(const TDesC& aAddr, const TDesC& aMsg)
Comment out the SendSMSInThirdEditionL call, since you need to use the older API.
Make your changes in:
TMsvId CSMSExampleMtmsEngine::CreateSMSMessageL(const TDesC& aAddress,
const TDesC& aMessage)
Alternatively, if what you want to achieve is to send an SMS every 4 days, then you can use the Symbian Task Scheduler to do this. You can create an EXE which sends the SMS, then create a task which will run the EXE every 4 days. It will not keep anything running in the background so it won't waste battery, and it will remember to run the task even if you reboot the phone in between runs, since it persists the schedule to disk.
This example
shows how to create a task - so in the DoRunTaskL function you can send an SMS, for instance.
This example
shows how to schedule the task itself.
So to start your SMS sending schedule you would need to do something like that but edit the schedule to be every 4 days.
I would say that this is a relatively advanced programming challenge on Symbian. So if you are new I'd recommend doing some of the tutorials, reading the books etc. before starting it.