How to report bugs?
Hello
Just buyed the 3.01 version (SoapUI PRO) and tried to port two middle sized projects (~2 MB) from 2.5 to the new version.
There is one show stopper bug which was not present in 2.5, three minor frictions which I cannot say if they are new or already present in 2.5, and a documented feature which does not work (or I make something wrong).
1. The UTF-8 character 0xC38F (an 'I' combined with a '^') within a prepared soap message (text content of string field) is saved back as 0xC33F, which is not a valid UTF-8 character. The project cannot be loaded again. Also the displaying (if loaded first with correct character) is scrumbled, but the character is sent correctly to the host. If I escape the character (Ï = Unicode of the same character): The message is sent correctly, the project is saved correctly, but if reloaded, soapUI transforms the escape sequence to the UTF-8 character again, with the above consequences when saving the project. (BTW: I run the SoapUI with java version jdk1.6.0-07). Other UTF-8 characters are handled correctly (e.g. 0xC38E or 0xC392).
2. A project opened in the GUI, closing the GUI without changing anything: There is a new (empty) "
3. We have start batches (for GUI and for standalone testrunner) located in our own test home (SVN controlled). There is a soapui-settings.xml and a soapui-workspace.xml in this root folder. Since it is included in the classpath when starting the JVM, this two files are picked up when starting the GUI, what is intended. But: When saving back the soapui-settings.xml, the file is written to the user-home directory instead of the actual test root where the file was picked up. This behaviour is ambivalent: On the one hand it's cool because user dependent settings (like the appearance of the GUI) belongs only to the user (and should not be shared among different developers), on the other hand it's not OK if there is a property changed which influences the test behaviour (e.g. changing the property WsdlSettings@cache-wsdls or HttpSettings@max_connections_per_host).
4. The dynamic variable "${#Project#name}" cannot be used in the -f option of the testrunner commandline. It is not resolved. Other references (e.g. ${#Env#SOME_SETTING}) are resolved correctly.
5. The commandline options -R and -F of the testrunner have no effect. Regardless what I specify in -R ("TestSuite", name of a TestSuite), or -F (e.g. -FPDF): no report is written (-f is specified, and the failure text reports are written there correctly). I could not find any example how to use this two options.
Please help on these issues.
Heri Bender
Ergonomics AG
Just buyed the 3.01 version (SoapUI PRO) and tried to port two middle sized projects (~2 MB) from 2.5 to the new version.
There is one show stopper bug which was not present in 2.5, three minor frictions which I cannot say if they are new or already present in 2.5, and a documented feature which does not work (or I make something wrong).
1. The UTF-8 character 0xC38F (an 'I' combined with a '^') within a prepared soap message (text content of string field) is saved back as 0xC33F, which is not a valid UTF-8 character. The project cannot be loaded again. Also the displaying (if loaded first with correct character) is scrumbled, but the character is sent correctly to the host. If I escape the character (Ï = Unicode of the same character): The message is sent correctly, the project is saved correctly, but if reloaded, soapUI transforms the escape sequence to the UTF-8 character again, with the above consequences when saving the project. (BTW: I run the SoapUI with java version jdk1.6.0-07). Other UTF-8 characters are handled correctly (e.g. 0xC38E or 0xC392).
2. A project opened in the GUI, closing the GUI without changing anything: There is a new (empty) "
3. We have start batches (for GUI and for standalone testrunner) located in our own test home (SVN controlled). There is a soapui-settings.xml and a soapui-workspace.xml in this root folder. Since it is included in the classpath when starting the JVM, this two files are picked up when starting the GUI, what is intended. But: When saving back the soapui-settings.xml, the file is written to the user-home directory instead of the actual test root where the file was picked up. This behaviour is ambivalent: On the one hand it's cool because user dependent settings (like the appearance of the GUI) belongs only to the user (and should not be shared among different developers), on the other hand it's not OK if there is a property changed which influences the test behaviour (e.g. changing the property WsdlSettings@cache-wsdls or HttpSettings@max_connections_per_host).
4. The dynamic variable "${#Project#name}" cannot be used in the -f option of the testrunner commandline. It is not resolved. Other references (e.g. ${#Env#SOME_SETTING}) are resolved correctly.
5. The commandline options -R and -F of the testrunner have no effect. Regardless what I specify in -R ("TestSuite", name of a TestSuite), or -F (e.g. -FPDF): no report is written (-f is specified, and the failure text reports are written there correctly). I could not find any example how to use this two options.
Please help on these issues.
Heri Bender
Ergonomics AG
