I would like to be able to run a set of unit tests by linking to them in my application (e.g. I want to be able to click on a link and have it run a set of jUnit tests). The problem is that GWT and jUnit don't seem to be designed for this capability -- only at build time can you run the tests it seems.
I would like to be able to include my test code in my application and, from onModuleLoad for example, run a set of tests.
I tried to just instantiate a test object:
StockWatcherTest tester = new StockWatcherTest();
tester.testSimple();
but I get:
No source code is available for type com.google.StockWatcher.client.StockWatcherTest;
even though I include the module specifically.
Would anyone know a way to do this? I just want to be able to display the test results within the browser.
If you are trying to test UI elements in GWT using JUnit, unfortunately you may not do so. JUnit testing is limited to RPC and non-UI client-side testing. See this thread for a great discussion on what you can and cannot do with GWT jUnit testing.
If you are not trying to test UI elements, but are instead trying to inject your RPC code or client-side logic with test values (hence why you want to be able to click on a link and run a set of JUnit tests), then you should follow the following guide from testearly.com: Testing GWT with JUnit. In short, you should make sure that the method you are testing does not include any UI elements and if the method you are testing is asynchronous in nature, you must add a timer.
In 2.0, HTMLUnit was added. You may wish to use this instead of firing up a browser each time you wish to test.
Related
The app I am trying to test makes use of feature toggles to enable/disable certain parts of the app. However, the tests I've written are for all the features. When a user logs in, this will fetch the feature toggles from a REST service (using a class which uses the generated openapi) so the app knows what to show and what not to show.
Now I want to include those feature toggles in my tests, so that the corresponding tests are skipped and don't just fail if some parts aren't enabled. However, when I try to include the class that does the call, I get problems with dart:ui in the console, and the test no longer runs. When I (recursively) check the imports on those service classes, there are some imports to widgets.dart, so I guess that's the problem. I tried removing most of it, but since we're using Localized strings for error messages etc. it's getting to be a very cumbersome job to remove all of that from those files.
So before I continue doing that, I was wondering if there is any easy way to include a call to a REST service in an integration test?
I checked the Flutter drive documentation, and searched for some similar questions online but haven't really found anything similar.
I am writing UI tests for a mobile app using Xamarin UI test and N-unit frameworks. I want to run a particular method (App initialization) only once before the set of tests began to run. I used [one time setup] annotation but that is also running before each test.Please help me on this.
You can do this by creating a [SetupFixture] outside of any namespace.
See the docs here: https://github.com/nunit/docs/wiki/SetUpFixture-Attribute
I have written a few tests for polymer elements in jasmine based on how Polymer wrote tests with Mocha for their components.I am able to run those tests successfully if I run them individually.
By taking a look at Polymer's core tests ,what I understand is that there is a custom test runner that uses mocha-htmltest.js to launch each of the polymer element tests(each an html in itself) in an iframe and then destroy it for every test.The results to display are passed to the main window for every test.
In this approach,each polymer element test html running within an iframe imports all the libraries needed(jasmine,platform,polymer).
Isn't this a costly approach to re-construct iframes importing all libraries for each element's test?
Is there any alternate ways for running multiple polymer element tests?
I could not find alternative approaches without one test polluting the other.(Faced issues like being able to listen to polymer-ready only for the first element test)
Can anyone share some thoughts on how you managed to run multiple polymer elements' tests with karma as the test runner?
Thanks,
vj.
We chose the iframe approach because we wanted to write tests in plain HTML without resorting to javascript innerHTML tricks, and we use karma to test in all of our supported browsers. iframes gives us both of our requirements, at the expense of taking a while to run.
I must note that we typically test a number of related things in iframes because the cost is so high. In that sense we use them at somewhere between a "suite" and a "test" in mocha's terminology.
Perhaps at some point in the future, a lighter layer can be made (ES6/7 Realms + ShadowDOM?) that gives us a clean context for our test runs, but the speed hit is not especially heinous to us for now.
When I run my selenium test without the turbolinks gem installed in my Ruby on Rails app, the tests pass. When I include turbolinks, the tests fail. For example if the test starts off
Open /
clickAndWait link=Sign in
type id=session_email any#example.com
Then I will get an error
"[error]Element id=session_email not found.
When I look at the page source, the session_email id is still there with turbolinks installed. I found this page, http://www.digitalkingdom.org/rlp/tiki-index.php?page=Selenium+And+Javascript, which seems to indicate there could be a problem with detecting the page has fully loaded.
Is there away to fix this without changing hundreds of lines in my test suites? If not, is there a reliable selenium method that can test that a turbolinked page has fully loaded?
After some help with the github turbolinks-compatability project, I am able to provide a partial answer to this question.
If the turbolinks gem is being used, then you will need to modify your selenium test cases in order to make sure the page is really loaded. For example, if your test has the following code in it
Open /
clickAndWait link=Sign in
type id=session_email any#example.com
then it needs to be modified to
Open /
click link=Sign in
waitForElementPresent id=session_email
type id=session_email any#example.com
There are a number of "waitFor" modifiers you can used, depending on what is the feature on the page you want to test next.
However, if the test involves a javascript pop up, then you should not add a waitFor command. So for example if you have at test like
clickAndWait link=Delete
assertConfirmation Are you Sure?
you should not modify the code. Indeed adding a waitFor test hangs execution in the case of javascript popups.
This solution involves line-by-line manual modification of the code. I have opened up an issue on the Selenium Users group to see if there is some better way to handle this problem.
I am developing a Play! 2 application that generates some html/js widgets which will be embedded into 3rd-party websites. Their linking are dynamic thus I cannot have static test files.
How can I have test views(and routes to those views) that works only in test mode, so I can test with Selenium.
Basically I want to add testView1.scala.html, testView1.scala.html to test/views and have routes to that, but do not want that these work in production mode. What is a good approach to that?
i'm not sure if this is the best way, but here is how i would do it.
create the test route and route to a test controller
in the test controller, create a wrapped action and have all of your routes use this action
this wrapped action will test to see what mode play is in. if play isnt in test mode, forward to 404, otherwise, run the action
when i get home, ill add some code to support, but this is the general workflow i would use.
hope it helps.
Simples...(now with years to answer..). A bit similar to what #mbseid answered:
Rename your /conf/routes to /conf/prod.routes, and specify it in your /conf/application.conf:
play.http.router = prod.Routes
Create a test routes file, e.g. /conf/test.routes, that exposes the test only route and delegates the rest to the prod routes.
/test/only/something controllers.testonly.TestOnlySomethingController.someMethod()
-> / prod.Routes
Make sure your test only controllers are in a different package than other controllers.
When you start your test application override play.http.router, e.g.:
sbt run -Dplay.http.router=test.Routes
It is a useful pattern in microservices environments with integration tests to expose data not otherwise exposed.
Note, play.http.router used to be called application.router before v2.5+