[JBoss JIRA] (ARQ-1332) Should be able to script data in the data sets
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1332?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-1332:
--------------------------------
Fix Version/s: persistence_1.0.0.next
> Should be able to script data in the data sets
> ----------------------------------------------
>
> Key: ARQ-1332
> URL: https://issues.jboss.org/browse/ARQ-1332
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Reporter: Bartosz Majsak
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> The DataSet represents a collection of tables (rows) used to seed the database. However it's static nature is not sufficient in many cases. Imagine testing time sensitive data. It could be really handy to have possibility of defining date as "three days from today" or having current time by simply invoking "now()" function. With the power of a scripting language at your disposal it should be achieved very easy.
>
> The goal of this project is to extend the Arquillian Persistence Extension usage of DBUnit and introduce the concept ScriptableDataSet. By leveraging "Scripting for the Java Platform" (JSR 223) introduced in JDK 6 we can use plethora of languages to add dynamic flavor to our data driven tests.
> Supporting a script location (and perhaps even a function in that script file) might be a nice addition as well. That externalizes the code and allows for reuse.
> As a starting point groovy can be considered.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-1645) persistence doesn't support multiple datasources
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1645?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-1645:
--------------------------------
Fix Version/s: persistence_1.0.0.next
> persistence doesn't support multiple datasources
> ------------------------------------------------
>
> Key: ARQ-1645
> URL: https://issues.jboss.org/browse/ARQ-1645
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha6
> Reporter: Romain Manni-Bucau
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> It is common to use multiple datsources (in fact all apps I'm working with does it) and ATM dbunit extension doesn't support multiple datsource init/asserts (UsingDataSet and ExpectedDataSet).
> Would be great to get a plural version of @DataSource and @XDataSet
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-1782) @UsingDataSet/@ShouldMatchDataSet always makes test succeed
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1782?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-1782:
--------------------------------
Fix Version/s: persistence_1.0.0.next
> @UsingDataSet/@ShouldMatchDataSet always makes test succeed
> -----------------------------------------------------------
>
> Key: ARQ-1782
> URL: https://issues.jboss.org/browse/ARQ-1782
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha7
> Environment: WildFly 8 CR 2
> Reporter: Nicklas Karlsson
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>fi.affecto.marela</groupId>
> <artifactId>arq-concept</artifactId>
> <version>1.0.0-SNAPSHOT</version>
> <packaging>jar</packaging>
> <properties>
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
> <browser>chrome</browser>
> </properties>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.jboss.arquillian</groupId>
> <artifactId>arquillian-bom</artifactId>
> <version>1.1.4.Final</version>
> <scope>import</scope>
> <type>pom</type>
> </dependency>
> <dependency>
> <groupId>org.jboss.arquillian.extension</groupId>
> <artifactId>arquillian-drone-bom</artifactId>
> <version>1.3.0.Final</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.arquillian.selenium</groupId>
> <artifactId>selenium-bom</artifactId>
> <version>2.41.0</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>4.11</version>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.arquillian.junit</groupId>
> <artifactId>arquillian-junit-container</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.hibernate</groupId>
> <artifactId>hibernate-jpamodelgen</artifactId>
> <version>4.3.5.Final</version>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.arquillian.graphene</groupId>
> <artifactId>graphene-webdriver</artifactId>
> <version>2.0.2.Final</version>
> <type>pom</type>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.arquillian.extension</groupId>
> <artifactId>arquillian-persistence-core</artifactId>
> <version>1.0.0.Alpha7</version>
> </dependency>
> <dependency>
> <groupId>org.jboss.arquillian.extension</groupId>
> <artifactId>arquillian-persistence-dbunit</artifactId>
> <version>1.0.0.Alpha7</version>
> </dependency>
> </dependencies>
> <profiles>
> <profile>
> <id>arq-wildfly</id>
> <dependencies>
> <dependency>
> <groupId>org.jboss.spec</groupId>
> <artifactId>jboss-javaee-7.0</artifactId>
> <version>1.0.0.Final</version>
> <type>pom</type>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-arquillian-container-remote</artifactId>
> <version>8.1.0.CR2</version>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.arquillian.protocol</groupId>
> <artifactId>arquillian-protocol-servlet</artifactId>
> <scope>test</scope>
> </dependency>
> </dependencies>
> </profile>
> </profiles>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>2.3.2</version>
> <configuration>
> <source>1.7</source>
> <target>1.7</target>
> </configuration>
> </plugin>
> </plugins>
> <testResources>
> <testResource>
> <directory>src/test/resources</directory>
> <filtering>true</filtering>
> </testResource>
> </testResources>
> </build>
> </project>
> {code}
> {code:java}
> package fi.affecto.marela.test;
> import javax.inject.Inject;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.transaction.UserTransaction;
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.arquillian.persistence.ShouldMatchDataSet;
> import org.jboss.arquillian.persistence.UsingDataSet;
> import org.jboss.arquillian.transaction.api.annotation.Transactional;
> import org.jboss.shrinkwrap.api.Archive;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.asset.EmptyAsset;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.junit.Assert;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import fi.affecto.marela.jpa.Game;
> @RunWith(Arquillian.class)
> public class PersistenceExtensionTest
> {
> @Deployment
> public static Archive<?> createDeployment()
> {
> return ShrinkWrap.create(WebArchive.class, "test.war").addPackage(Game.class.getPackage())
> .addAsResource("persistence.xml", "META-INF/persistence.xml")
> .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @PersistenceContext
> EntityManager em;
> @Inject
> UserTransaction utx;
> @Test
> public void testA() throws Exception
> {
> Assert.assertNotNull(em);
> utx.begin();
> // em.joinTransaction();
> Game g = new Game();
> g.setId(666L);
> g.setTitle("x");
> Assert.assertFalse(em.contains(g));
> g = em.merge(g);
> Assert.assertTrue(em.contains(g));
> utx.rollback();
> }
>
> @Test
> @Transactional
> public void testB() throws Exception
> {
> Assert.assertNotNull(em);
> Game g = new Game();
> g.setId(666L);
> g.setTitle("x");
> Assert.assertFalse(em.contains(g));
> g = em.merge(g);
> Assert.assertTrue(em.contains(g));
> }
> @Test
> // @UsingDataSet("games.yml")
> // @ShouldMatchDataSet("games-check.yml")
> @Transactional
> public void testC() throws Exception
> {
> Assert.assertTrue(false);
> }
> }
> {code}
> testC succeeds if the annotations are uncommented.
> Furthermore, there is something strange with the em/transactions, the persistence works even if the em doesn't join the transaction and the em complains of a detached instance if merge() is switched for persist()
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-1809) @ShouldMatchDataSet is broken when ordering by non-string columns
by Steven Dodd (JIRA)
[ https://issues.jboss.org/browse/ARQ-1809?page=com.atlassian.jira.plugin.s... ]
Steven Dodd updated ARQ-1809:
-----------------------------
Description:
Steps to reproduce:
1. Create a table, "test", with a single column, an integer primary key, "id".
2. Try the following test case under the persistence extension:
{code}
@UsingDataSet({test.yml})
@ShouldMatchDataSet(value={test.yml})
@Test
public void test() {
// do nothing
}
{code}
{code:title=test.yml}
test:
- id: -1
- id: -2
{code}
Result: test fails like so:
{code}
java.lang.AssertionError: Test failed in 2 cases.
test | In row 0: expected value of id "-1" but was "-2".
test | In row 1: expected value of id "-2" but was "-1".
{code}
Reason:
The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison.
SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
Suggested Fix:
The expected dataset needs to have accurate column types assigned, not UNKNOWN.
was:
Steps to reproduce:
1. Create a table, "test", with a single column, an integer primary key, "id".
2. Try the following test case under the persistence extension:
{code}
@UsingDataSet({test.yml})
@ShouldMatchDataSet(value={test.yml})
@Test
public void test() {
// do nothing
}
{code}
{code:title=test.yml}
test:
- id: -1
- id: -2
{code}
Result: test fails like so:
{code}
java.lang.AssertionError: Test failed in 4 cases.
test | In row 0: expected value of id "-1" but was "-2".
test | In row 1: expected value of id "-2" but was "-1".
{code}
Reason:
The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison.
SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
Suggested Fix:
The expected dataset needs to have accurate column types assigned, not UNKNOWN.
> @ShouldMatchDataSet is broken when ordering by non-string columns
> -----------------------------------------------------------------
>
> Key: ARQ-1809
> URL: https://issues.jboss.org/browse/ARQ-1809
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha7
> Reporter: Steven Dodd
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> Steps to reproduce:
> 1. Create a table, "test", with a single column, an integer primary key, "id".
> 2. Try the following test case under the persistence extension:
> {code}
> @UsingDataSet({test.yml})
> @ShouldMatchDataSet(value={test.yml})
> @Test
> public void test() {
> // do nothing
> }
> {code}
> {code:title=test.yml}
> test:
> - id: -1
> - id: -2
> {code}
> Result: test fails like so:
> {code}
> java.lang.AssertionError: Test failed in 2 cases.
> test | In row 0: expected value of id "-1" but was "-2".
> test | In row 1: expected value of id "-2" but was "-1".
> {code}
> Reason:
> The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
> The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
> DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison.
> SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
> As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
> Suggested Fix:
> The expected dataset needs to have accurate column types assigned, not UNKNOWN.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-1809) @ShouldMatchDataSet is broken when ordering by non-string columns
by Steven Dodd (JIRA)
[ https://issues.jboss.org/browse/ARQ-1809?page=com.atlassian.jira.plugin.s... ]
Steven Dodd updated ARQ-1809:
-----------------------------
Description:
Steps to reproduce:
1. Create a table, "test", with a single column, an integer primary key, "id".
2. Try the following test case under the persistence extension:
{code}
@UsingDataSet({test.yml})
@ShouldMatchDataSet(value={test.yml})
@Test
public void test() {
// do nothing
}
{code}
{code:title=test.yml}
test:
- id: -1
- id: -2
{code}
Result: test fails like so:
{code}
java.lang.AssertionError: Test failed in 4 cases.
test | In row 0: expected value of id "-1" but was "-2".
test | In row 1: expected value of id "-2" but was "-1".
{code}
Reason:
The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison.
SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
Suggested Fix:
The expected dataset needs to have accurate column types assigned, not UNKNOWN.
was:
Steps to reproduce:
1. Create a table, "test", with a single column, an integer primary key, "id".
2. Try the following test case under the persistence extension:
{code}
@UsingDataSet({test.yml})
@ShouldMatchDataSet(value={test.yml})
@Test
public void test() {
// do nothing
}
{code}
{code:title=test.yml}
test:
- id: -1
- id: -2
{code}
Result: test fails like so:
{code}
java.lang.AssertionError: Test failed in 4 cases.
test | In row 0: expected value of id "-1" but was "-2".
test | In row 0: expected value of owner_id "-1" but was "-2".
test | In row 1: expected value of id "-2" but was "-1".
test | In row 1: expected value of owner_id "-2" but was "-1".
{code}
Reason:
The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison.
SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
Suggested Fix:
The expected dataset needs to have accurate column types assigned, not UNKNOWN.
> @ShouldMatchDataSet is broken when ordering by non-string columns
> -----------------------------------------------------------------
>
> Key: ARQ-1809
> URL: https://issues.jboss.org/browse/ARQ-1809
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha7
> Reporter: Steven Dodd
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> Steps to reproduce:
> 1. Create a table, "test", with a single column, an integer primary key, "id".
> 2. Try the following test case under the persistence extension:
> {code}
> @UsingDataSet({test.yml})
> @ShouldMatchDataSet(value={test.yml})
> @Test
> public void test() {
> // do nothing
> }
> {code}
> {code:title=test.yml}
> test:
> - id: -1
> - id: -2
> {code}
> Result: test fails like so:
> {code}
> java.lang.AssertionError: Test failed in 4 cases.
> test | In row 0: expected value of id "-1" but was "-2".
> test | In row 1: expected value of id "-2" but was "-1".
> {code}
> Reason:
> The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
> The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
> DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison.
> SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
> As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
> Suggested Fix:
> The expected dataset needs to have accurate column types assigned, not UNKNOWN.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-1809) @ShouldMatchDataSet is broken when ordering by non-string columns
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1809?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-1809:
--------------------------------
Fix Version/s: persistence_1.0.0.next
> @ShouldMatchDataSet is broken when ordering by non-string columns
> -----------------------------------------------------------------
>
> Key: ARQ-1809
> URL: https://issues.jboss.org/browse/ARQ-1809
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha7
> Reporter: Steven Dodd
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> Steps to reproduce:
> 1. Create a table, "test", with a single column, an integer primary key, "id".
> 2. Try the following test case under the persistence extension:
> {code}
> @UsingDataSet({test.yml})
> @ShouldMatchDataSet(value={test.yml})
> @Test
> public void test() {
> // do nothing
> }
> {code}
> {code:title=test.yml}
> test:
> - id: -1
> - id: -2
> {code}
> Result: test fails like so:
> {code}
> java.lang.AssertionError: Test failed in 4 cases.
> test | In row 0: expected value of id "-1" but was "-2".
> test | In row 0: expected value of owner_id "-1" but was "-2".
> test | In row 1: expected value of id "-2" but was "-1".
> test | In row 1: expected value of owner_id "-2" but was "-1".
> {code}
> Reason:
> The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
> The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
> DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison.
> SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
> As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
> Suggested Fix:
> The expected dataset needs to have accurate column types assigned, not UNKNOWN.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-1809) @ShouldMatchDataSet is broken when ordering by non-string columns
by Steven Dodd (JIRA)
[ https://issues.jboss.org/browse/ARQ-1809?page=com.atlassian.jira.plugin.s... ]
Steven Dodd updated ARQ-1809:
-----------------------------
Description:
Steps to reproduce:
1. Create a table, "test", with a single column, an integer primary key, "id".
2. Try the following test case under the persistence extension:
{code}
@UsingDataSet({test.yml})
@ShouldMatchDataSet(value={test.yml})
@Test
public void test() {
// do nothing
}
{code}
{code:title=test.yml}
test:
- id: -1
- id: -2
{code}
Result: test fails like so:
{code}
java.lang.AssertionError: Test failed in 4 cases.
test | In row 0: expected value of id "-1" but was "-2".
test | In row 0: expected value of owner_id "-1" but was "-2".
test | In row 1: expected value of id "-2" but was "-1".
test | In row 1: expected value of owner_id "-2" but was "-1".
{code}
Reason:
The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison.
SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
Suggested Fix:
The expected dataset needs to have accurate column types assigned, not UNKNOWN.
was:
Steps to reproduce:
1. Create a table, "test", with a single column, an integer primary key, "id".
2. Try the following test case under the persistence extension:
{code}
@UsingDataSet({test.yml})
@ShouldMatchDataSet(value={test.yml})
@Test
public void test() {
// do nothing
}
{code}
{code:title=test.yml}
test:
- id: -1
- id: -2
{code}
Result: test fails like so:
{code}
java.lang.AssertionError: Test failed in 4 cases.
test | In row 0: expected value of id "-1" but was "-2".
test | In row 0: expected value of owner_id "-1" but was "-2".
test | In row 1: expected value of id "-2" but was "-1".
test | In row 1: expected value of owner_id "-2" but was "-1".
{code}
Reason:
The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
DataSetComparator wraps each dataset in a SortedTable, to provide a consistent ordering for comparison.
SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
As a result, the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
Suggested Fix:
The expected dataset needs to have accurate column types assigned, not UNKNOWN.
> @ShouldMatchDataSet is broken when ordering by non-string columns
> -----------------------------------------------------------------
>
> Key: ARQ-1809
> URL: https://issues.jboss.org/browse/ARQ-1809
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha7
> Reporter: Steven Dodd
> Assignee: Bartosz Majsak
>
> Steps to reproduce:
> 1. Create a table, "test", with a single column, an integer primary key, "id".
> 2. Try the following test case under the persistence extension:
> {code}
> @UsingDataSet({test.yml})
> @ShouldMatchDataSet(value={test.yml})
> @Test
> public void test() {
> // do nothing
> }
> {code}
> {code:title=test.yml}
> test:
> - id: -1
> - id: -2
> {code}
> Result: test fails like so:
> {code}
> java.lang.AssertionError: Test failed in 4 cases.
> test | In row 0: expected value of id "-1" but was "-2".
> test | In row 0: expected value of owner_id "-1" but was "-2".
> test | In row 1: expected value of id "-2" but was "-1".
> test | In row 1: expected value of owner_id "-2" but was "-1".
> {code}
> Reason:
> The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
> The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
> DataSetComparator wraps each dataset in a SortedTable, to provide a consistent row ordering for comparison.
> SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
> As a result, the rows of the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
> Suggested Fix:
> The expected dataset needs to have accurate column types assigned, not UNKNOWN.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-1809) @ShouldMatchDataSet is broken when ordering by non-string columns
by Steven Dodd (JIRA)
[ https://issues.jboss.org/browse/ARQ-1809?page=com.atlassian.jira.plugin.s... ]
Steven Dodd updated ARQ-1809:
-----------------------------
Description:
Steps to reproduce:
1. Create a table, "test", with a single column, an integer primary key, "id".
2. Try the following test case under the persistence extension:
{code}
@UsingDataSet({test.yml})
@ShouldMatchDataSet(value={test.yml})
@Test
public void test() {
// do nothing
}
{code}
{code:title=test.yml}
test:
- id: -1
- id: -2
{code}
Result: test fails like so:
{code}
java.lang.AssertionError: Test failed in 4 cases.
test | In row 0: expected value of id "-1" but was "-2".
test | In row 0: expected value of owner_id "-1" but was "-2".
test | In row 1: expected value of id "-2" but was "-1".
test | In row 1: expected value of owner_id "-2" but was "-1".
{code}
Reason:
The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
DataSetComparator wraps each dataset in a SortedTable, to provide a consistent ordering for comparison.
SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
As a result, the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
Suggested Fix:
The expected dataset needs to have accurate column types assigned, not UNKNOWN.
was:
Steps to reproduce:
1. Create a table, "test", with a single column, an integer primary key, "id".
2. Try the following test case under the persistence extension:
{code}
@UsingDataSet({test.yml})
@ShouldMatchDataSet(value={test.yml})
@Test
public void test() {
// do nothing
}
{code}
{code:title=test.yml}
test:
- id: -1
- id: -2
{code}
Result: test fails.
Reason:
The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
DataSetComparator wraps each dataset in a SortedTable, to provide a consistent ordering for comparison.
SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
As a result, the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
Suggested Fix:
The expected dataset needs to have accurate column types assigned, not UNKNOWN.
> @ShouldMatchDataSet is broken when ordering by non-string columns
> -----------------------------------------------------------------
>
> Key: ARQ-1809
> URL: https://issues.jboss.org/browse/ARQ-1809
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha7
> Reporter: Steven Dodd
> Assignee: Bartosz Majsak
>
> Steps to reproduce:
> 1. Create a table, "test", with a single column, an integer primary key, "id".
> 2. Try the following test case under the persistence extension:
> {code}
> @UsingDataSet({test.yml})
> @ShouldMatchDataSet(value={test.yml})
> @Test
> public void test() {
> // do nothing
> }
> {code}
> {code:title=test.yml}
> test:
> - id: -1
> - id: -2
> {code}
> Result: test fails like so:
> {code}
> java.lang.AssertionError: Test failed in 4 cases.
> test | In row 0: expected value of id "-1" but was "-2".
> test | In row 0: expected value of owner_id "-1" but was "-2".
> test | In row 1: expected value of id "-2" but was "-1".
> test | In row 1: expected value of owner_id "-2" but was "-1".
> {code}
> Reason:
> The expected dataset is loaded by the YamlDataSetProducer, and has all of its column types set to UNKNOWN.
> The actual dataset is loaded by <whatever>, and has all of its column types set to their actual types in the database.
> DataSetComparator wraps each dataset in a SortedTable, to provide a consistent ordering for comparison.
> SortedTable ends up sorting every column of the expected dataset as strings, because the column types are UNKNOWN, but it sorts the actual dataset columns using their actual column types, e.g. numeric sort in the test case above.
> As a result, the expected and actual datasets are not consistently sorted for comparison, which results in totally inaccurate comparison results.
> Suggested Fix:
> The expected dataset needs to have accurate column types assigned, not UNKNOWN.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months