I am writing a regression suite for API's using SCALATEST, I am kind of stuck-up with following scenario:
For instance I have two tests:
test-1{
Call for API-1
Call for API-2
Call for API-3
}
test-2{
Call for API-5
Call for API-6
Call for API-7
}
I have created a generalized function to Call API's I have setup separate JSON files for URI, method, body and headers.
Now my question is that as all these calls will be async, and will be getting back Future Results, one way to handle I know is flatmap / or For within one Test.
But what about 2nd Test, do I need to block main thread here or there is some smart solution for this. I can't afford to run multiple cases in parallel due to inter-dependencies on resources they will be using.
It's better for your tests be executed sequentially, for this please refer to the scalatest user guide on how to deal with Futures
Play will also provide you some utils to handle a Future, the usage is described in the testing documentation
Related
-1
Could someone help me. I have a hard time to implement UITests and store the result for future upload to TestRail (when all tests is completed.
I have testRailmanager with two method
createRun() (this method make api call returning testRunID used by second endpoint)
sendResults([TestResult]]
Everything is working if I have only one XCTestCase with multiple test methods for example: RegistrationUITests: XCTestcase)
Unfortunately if I add multiple files with multiple XCTestCase like this and run parallel tests
TestLoginUITests.swift
TestDashboardUITests.swift
TestEventsUITests.swift etc. the manager is not shared between test.
I tried singleton TestRailManager.shared, I tried have a manager as global constant. But nothing
What is the easiest way to share the data between multiple XCTests classes running parralel? Thank you
We recently migrated from MongoBee to Mongock, and with Mongock 5 version the #ChangeLog and #ChangeSet are depricated. Writing the #ChangeUnit is easy enough and rollback methods are very helpful.
However, I'm unable to figure out how to write a test simulating the migration in test DB and validating the changes in DB, as there are #BeforeExecution, #RollbackBeforeExecution, #Execution and #RollbackExecution attributes or lifecycle methods in a #ChangeUnit.
Earlier, I used to just call the method with #ChangeSet annotation like
assertOriginalStructure();
someMigrationChangeLog.updateIndexOnSomething();
assertIndexUpdated();
Now, I'm unsure if there is a clean way to write the above test as there is some logic in #BeforeExecution and also in #Execution. I know individually calling the annotated methods will work, but I wanted to know if there is a way to just run one #ChangeUnit as a whole.
In the new version 5, the basic change is that a ChangeUnit holds the unit of execution. That's normally done in the method annotated with #Execution, so the first approach is just doing the same you are doing but calling the #Execution method:
assertOriginalStructure();
someMigrationChangeUnit.updateIndexOnSomething();//annotated with #Execution
assertIndexUpdated();
However, your ChangeUnit can also provide#BeforeExecution, which would be used to perform any action that cannot be within the execution, for example, in a transactional MongoDB migration, DDL are not allowed inside a transaction, so that would be done in the #BeforeExecution. So if your changeUnit has both, #Execution and #BeforeExecution, you should do this:
assertOriginalStructure();
someMigrationChangeUnit.beforeExecution();//annotated with #BeforeExecution
someMigrationChangeUnit.updateIndexOnSomething();//annotated with #Execution
assertIndexUpdated();
I'm building a library that, as part of its functionality, makes HTTP requests. To get it to work in the multiple environments it'll be deployed in I'd like it to be able to work with or without Futures.
One option is to have the library parametrise the type of its response so you can create an instance of the library with type Future, or an instance with type Id, depending on whether you are using an asynchronous HTTP implementation. (Id might be an Identity monad - enough to expose a consistent interface to users)
I've started with that approach but it has got complicated. What I'd really like to do instead is use the Future type everywhere, boxing synchronous responses in a Future where necessary. However, I understand that using Futures will always entail some kind of threadpool. This won't fly in e.g. AppEngine (a required environment).
Is there a way to create a Future from a value that will be executed on the current thread and thus not cause problems in environments where it isn't possible to spawn threads?
(p.s. as an additional requirement, I need to be able to cross build the library back to Scala v2.9.1 which might limit the features available in scala.concurrent)
From what I understand you wish to execute something and then wrap the result with Future. In that case, you can always use Promise
val p = Promise[Int]
p success 42
val f = p.future
Hence you now have a future wrapper containing the final value 42
Promise is very well explained here .
Take a look at Scalaz version of Future trait. That's based on top of Trampoline mechanism which will be executing by the current thread unless fork or apply won't be called + that completely removes all ExecutionContext imports =)
I'm relatively new to unit testing and i'm trying to figure out a way to test an XHR request in a meaningful way.
1) The request pulls in various scripts and other resources onto the page, I want to make sure the correct number of resources are being loaded, and that the request is successful.
2) Should I use an actual request to the service that is providing the resource? I looked at fakeserver and fakexhr request on sinonjs.org, but I don't really get how those can provide a meaningful test.
3) I'm testing existing code, which I realize is pretty pointless, but it's what i'm required to do. That being said, there is alot of code in certain methods which could potentially be broken down into various tests. Should I break the existing code down and create tests for my interpreted expectation? Or just write tests for what is actually there?.... if that makes any sense.
Thanks,
-John
I find it useful to use the sinon fakeServer to return various test responses that will exercise my client-side functions. You can set up a series of tests in which a fakeServer response returns data that you can use to subsequently check the behaviour of your code. For example, suppose you expect ten resource objects to be returned, you can create pre-canned xml or json to represent those resources and then check that your code has handled them properly. In another test, what does your code do when you only receive nine objects?
Begin writing your tests to cover your existing code. When those tests pass, begin breaking up your code into easier-to-understand and meaningful units. If the tests still pass, then great, you've just refactored your code and not inadvertently broken anything. Also, now you've got smaller chunks of code that can more readily be tested and understood. From this point on you'll never look back :-)
I have a Scala application that relies on an external RESTful webservice for some part of its functionality. We'd like to do some performance tests on the application, so we stub out the webservice with an internal class that fakes the response.
One thing we would like to keep in order to make the performance test as realistic as possible is the network lag and response time from the remote host. This is between 50 and 500 msec (we measured).
Our first attempt was to simply do a Thread.sleep(random.nextInt(450) + 50), however I don't think that's accurate - we use NIO, which is non-blocking, and Thread.sleep is blocking and locks up the whole thread.
Is there a (relatively easy / short) way to stub a method that contacts an external resource, then returns and calls a callback object when ready? The bit of code we would like to replace with a stub implementation is as follows (using Sonatype's AsyncHttpClient), where we wrap its completion handler object in one of our own that does some processing:
def getActualTravelPlan(trip: Trip, completionHandler: AsyncRequestCompletionHandler) {
val client = clientFactory.getHttpClient
val handler = new TravelPlanCompletionHandler(completionHandler)
// non-blocking call here.
client.prepareGet(buildApiURL(trip)).setRealm(realm).execute(handler)
}
Our current implementation does a Thread.sleep in the method, but that's, like I said, blocking and thus wrong.
Use a ScheduledExecutorService. It will allow you to schedule things to run at some time in the future. Executors has factory methods for creating them fairly simply.