We are looking forward to using squashTA to manage our tests. The problem we are facing is that we already have a big automated tests collection and aren't able to make them run via squash TM using squash TA.
Our tests are using junit+selenium WebDriver+SpringFramework.
Currently, we launch our automated tests via maven (in commandLine), and we have a jenkins server running them regularly.
We tried to reuse our tests in a squash TA project, putting them in src/squashta/resources/selenium/java
But code in this folder doesn't even support java packages. It's like the java in the example isn't real java but a fake java parse by squashTA.
Is there any mean of using such already existing tests with squash(TA/TM) ?
Or, any alternatives you know that could do the job ? (we are currently using testlink and must change).
If your selenium test is in :
src/squashTA/resources/selenium-test/src/main/java/org/squashtest/ta/selenium/PetStoreTest.java
With a such structure, the test automation script to run the selenium test (which is in the package org.squashtest.ta.selenium) is :
TEST :
LOAD selenium-test/src/test AS seleniumTestSource
CONVERT seleniumTestSource TO script.java(compile) AS seleniumTestCompiled
CONVERT seleniumTestCompiled TO script.java.selenium2(script) USING $(org.squashtest.ta.selenium.PetStoreTest) AS seleniumTest
EXECUTE execute WITH seleniumTest AS seleniumResult
ASSERT seleniumResult IS success
If your selenium test has some dependencies to other libraries (like to spring in your case), you have to add those depencencies as dependency of the squash-ta-maven-plugin in the pom.xml of your Squash TA project
Related
I have recently upgraded to version 1.0.0 from 0.9.6 and noticed that the generated karate-summary.html file, it doesn't display all the tested feature files in the JUnit 5 Runner unlike in 0.9.6.
What it displays instead was the last tested feature file only.
The below screenshots are from the provided SampleTest.java sample code (excluding other Tests for simplicity).
package karate;
import com.intuit.karate.junit5.Karate;
class SampleTest {
#Karate.Test
Karate testSample() {
return Karate.run("sample").relativeTo(getClass());
}
#Karate.Test
Karate testTags() {
return Karate.run("tags").relativeTo(getClass());
}
}
This is from Version 0.9.6.
And this one is from Version 1.0.0
However, when running the test below in 1.0.0, all the features are displayed in the summary correctly.
#Karate.Test
Karate testAll() {
return Karate.run().relativeTo(getClass());
}
Would anyone be kind to confirm if they are getting the similar result? It would be very much appreciated.
What it displays instead was the last tested feature file only.
This is because for each time you run a JUnit method, the reports directory is backed up by default. Look for other directories called target/karate-reports-<timestamp> and you may find your reports there. So maybe what is happening is that you have multiple JUnit tests that are all running, so you see this behavior. You may be able to over-ride this behavior by calling the method: .backupReportDir(false) on the builder. But I think it may not still work - because the JUnit runner has changed a little bit. It is designed to run one method at a time, when you are in local / dev-mode.
So the JUnit runner is just a convenience. You should use the Runner class / builder for CI execution, and when you want to run multiple tests and see them in one report: https://stackoverflow.com/a/65578167/143475
Here is an example: ExamplesTest.java
But in case there is a bug in the JUnit runner (which is quite possible) please follow the process and help the project developers replicate and then fix the issue to release as soon as possible.
I am very new to rockdb and will be using the rocksdb in my application as a lookup service. Does the rockDBjava library api provided contain the database itself, I mean is it not necessary to install rocksDB database separately.
I tried running the code using library and see some files created in the db path I mentioned in code, so not sure how exactly it works and if I need to install DB separately or if the library stores data in the directory and it itself acts as database?
No, you should not need to install RocksDB separately if you already have RocksJava working. They're not very clear on stating that, but if you look at the wiki in their Git repo you'll find this:
RocksJava is structured in 3 layers:
The Java classes within the org.rocksdb package which form the
RocksJava API. Java users only directly interact with this layer.
JNI code written in C++ that provides the link between the Java API
and RocksDB.
RocksDB itself written in C++ and compiled into a native library which
is used by the JNI layer.
That third point is basically their way of saying that RocksDB itself is one of the layers of RocksJava.
How do I create integration tests when leveraging Xamarin.Forms?
Specifically, I do NOT want to rely on UI automation to test integration between the components of a system (i.e. database using SQLite).
I want my integration tests to target the layer beneath the UI.
For this I would recommend xUnit (there are others as well), that can test directly against PCL's. The native projects should be fairly empty and your ViewModels and Views should be void of most code, which means you can test directly on the Model and below.
Place a mock ISQLite DB connection to test the code without the SQLite DB, or place another one in that actually connects to a local SQLite DB, either way.
xUnit Project
https://github.com/xunit/devices.xunit
Though download the packages from NuGet, its easier. Then the test can also be run from VS which is a nice addition.
In one vein of thought I would like to configure a build with a custom task that will serve instead of the test default task. I will not be registering it as an "sbt test framework" as I'd like to avoid the syntax, limitations and history that comes with that. For example I'd like more flexibility in formatting, storing and sending test results.
Would it be possible introducing an sbt task to mimic sbt's default test task, in the following essential senses:
depend on compilation
be a dependency for other tasks such as artifact publishing tasks, and have them depend on a success return value from it
be able to provide it with library dependencies which will be excluded from final publishable artifacts
be able to control it just like any other task dependency
etc
Alternatively, are you able to delineate the structure of the mostly undocumented sbt TestFramework interface to a level that it's straightforward having your own formatting, test output logic, and test results publishing code, in your TestFramework implementation? I have mostly failed locating scalaTest's implementation of it.
Thanks in advance for you answers on both techniques.
I recently created a Meteor package and want to write some tests. What my test package basically do is that users can insert into the template {{> abc}} and they'll get an HTML element printed on the page.
With TinyTest, all you can do is test the package's API using something like test.equal(actual, expected, message, not). However, I need it to test whether the element was successfully printed on the page. Furthermore, I will pass the template some parameters and test them too.
It seems like I'd have to create a dummy app, run bash to initiate the app, and test whether the elements can be found on page. So should I only use TinyTest to test the API, and write my own tests (somehow!) for templating? If not, how should I go about it?
I read something about Blaze.toHTML, but I cannot find anything in the documentation on it? Nor it's source page.
I think TinyTest is great for starting with Unit testing, but what you need sounds more like an Integration test.
I would recommend you look into the following links for more info on testing with Meteor, especially with Velocity - Meteor's official testing framework:
Announcing Velocity: the official testing framework for Meteor applications
Velocity
The Meteor Testing Manual
You can create a demo application, and run integration tests using Mocha or Jasmine.