Re: [QA AUTOMATION] Insert Sheet Tests
Hi Matthias, On 10/18/22 09:08, Matthias Seidel wrote: Hi Carl, Thanks for the info and your continuing QA work! I *think* the problem with "Update Links" came up when we introduced a confirmation because of security reasons. https://bz.apache.org/ooo/show_bug.cgi?id=127582 I guessed it was due to a change at some point. Thanks for the link and all you do as well ;) Best regards, Carl Regards, Matthias Am 18.10.22 um 14:57 schrieb Carl Marcum: Hi All, There was an UNO FVT test uno/sc/sheetSheetBasicTest that was timing out and throwing an error due to an "Update Links" confirmation dialog that was waiting on a response that never comes. This test created a source Excel spreadsheet with a formula in a cell on each of three sheets and created a Calc document to copy these sheets into it with each of the three linking modes: Normal, Value, and None. I wasn't able to get past the dialog using UNO only so I have set that test to be ignored and created two additional mixed UNO/VCL test classes to cover it. mix/sc/sheet/InsertExcelSheetTest and InsertCalcSheetTest and instead of one large test method it's one for each of the three link modes and a class for Excel on one for Calc source documents. Using VCL I was able to acknowledge the dialog and move on and then use as much UNO after that. I also added a do while loop to retry a VCL call that randomly throws an VCLHookException so we don't fail a test because the dispatch glitched. (This same method loop might also fix some other flaky tests also.) More information in the PR [1]. [1] https://github.com/apache/openoffice/pull/158 Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
[QA AUTOMATION] Insert Sheet Tests
Hi All, There was an UNO FVT test uno/sc/sheetSheetBasicTest that was timing out and throwing an error due to an "Update Links" confirmation dialog that was waiting on a response that never comes. This test created a source Excel spreadsheet with a formula in a cell on each of three sheets and created a Calc document to copy these sheets into it with each of the three linking modes: Normal, Value, and None. I wasn't able to get past the dialog using UNO only so I have set that test to be ignored and created two additional mixed UNO/VCL test classes to cover it. mix/sc/sheet/InsertExcelSheetTest and InsertCalcSheetTest and instead of one large test method it's one for each of the three link modes and a class for Excel on one for Calc source documents. Using VCL I was able to acknowledge the dialog and move on and then use as much UNO after that. I also added a do while loop to retry a VCL call that randomly throws an VCLHookException so we don't fail a test because the dispatch glitched. (This same method loop might also fix some other flaky tests also.) More information in the PR [1]. [1] https://github.com/apache/openoffice/pull/158 Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Value returned by CInt("+1")
Hi Czesław, On 6/23/22 11:18 AM, Czesław Wolański wrote: Hi all, Bugzilla issue 128518 - Basic - Converting "+1" to a number https://bz.apache.org/ooo/show_bug.cgi?id=128518 Regards, Czesław - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org Thanks for entering it in bz. Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Value returned by CInt("+1")
Hi Czesław,
On 6/16/22 6:58 AM, Czesław Wolański wrote:
Hi,
The problem was reported yesterday on the English forum: topic "CINT("+1")
returns 0".
https://forum.openoffice.org/en/forum/viewtopic.php?p=525249=0481325a63f94adf45c49ba4175701d7#p525249
In version 4.1.12, CLng("+1") returns 0 too.
I haven't found any relevant report in Bugzilla. Do you think this problem
is "Bugzilla-worthy"?
Kind regards,
Czesław
If anything I think the bug is that it doesn't throw a runtime exception
and returns an unexpected value.
Not that it doesn't accept the + when used with a string like "+1".
I see that VBA does handle this now. I don't know if that was always the
case.
The help text states"
"... To convert a string expression, the number must be entered as
normal text ("123.5") using the default number format of your operating
system."
If I enter +1 into a cell my default number format changes it to a 1.
I haven't found any number format options where positive values have a
leading + but I haven't checked them all.
Beside the bug for the runtime exception there could be an enhancement
request to handle the + leading the string value since VBA and LO have
added it.
Just my opinion.
Best regards,
Carl
-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Value returned by CInt("+1")
Hi Czesław,
On 6/16/22 6:58 AM, Czesław Wolański wrote:
Hi,
The problem was reported yesterday on the English forum: topic "CINT("+1")
returns 0".
https://forum.openoffice.org/en/forum/viewtopic.php?p=525249=0481325a63f94adf45c49ba4175701d7#p525249
In version 4.1.12, CLng("+1") returns 0 too.
I haven't found any relevant report in Bugzilla. Do you think this problem
is "Bugzilla-worthy"?
Kind regards,
Czesław
Can you test this in a build of trunk and AOO41X?
If not I can this evening.
I've recently found things like this fixed in trunk many years ago but
not backported into AOO41X.
One involved CLng that has recently been added.
Thanks,
Carl
-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bug report : comment after "if ... then ... else"
Hi Lucien, On 6/16/22 4:36 AM, Lucien Mathay wrote: Thanks Mathias for introducing this part of the team ; I will also introduce myself : I am the developer of a program in VB, and I now start to translate it into Basic. It has some complexity. You might hear more from me in the future if I discover other strange things. Welcome and thanks again for the contribution! Good luck on your application. Best regards, Carl Best regards, Lucien. Le 15/06/22 à 16:57, Matthias Seidel a écrit : Hi Lucien, I only did provide the build. Carl found the fix and backported it... Thanks Carl for finding it and Damjan for fixing it in the first place! ;-) Regards, Matthias Le 14/06/22 à 16:52, Matthias Seidel a écrit : Hi Lucien, Please find my latest builds for Windows here: https://home.apache.org/~mseidel/AOO-builds/AOO-4113-Test/Full%20Installation/ Regards, Matthias Am 13.06.22 um 19:05 schrieb Matthias Seidel: Hi Lucien, Am 13.06.22 um 18:23 schrieb Lucien Mathay: Hi Mathias, yes, I can test it out with pleasure. Great! I use Windows XP. It's the easiest for me, but I can also have access to a Windows 10. Windows XP *should* work. Try that and if you find the time test on Win 10... I will start a new build now and will come back when finished and uploaded. Regards, Matthias Regards, Lucien. Le 11/06/22 à 16:51, Matthias Seidel a écrit : Hi Carl, Now that the fix is in AOO41X I will prepare a new build (for Windows). Maybe Lucien can test/confirm the issue is solved? @Lucien: What OS do you use? Regards, Matthias Am 07.06.22 um 23:23 schrieb Carl Marcum: Hi Matthias, On 6/7/22 6:53 AM, Matthias Seidel wrote: Hi Carl, Am 07.06.22 um 00:59 schrieb Carl Marcum: Hi Lucien, On 6/6/22 12:51 PM, Lucien Mathay wrote: Thank you Regina, but if I add an 'endif' at the end of the line ( " if a = b then a=1 Else a=2 endif 'test "), the compiler fails with the message "Syntax error : unexpectes symbol : End If". Furthermore, the book from "OpenOffice .org Macros OoOffice et Apis" from Bernard Marcelly and Laurent Goddard states p.118 : "Lorsqu’une seule instruction suffit dans la partie Then et dans la partie Else, la séquence peut s’écrire sur une seule ligne : If expr1 Then instruction1v Else instruction1f Notez l’absence du End If dans cette forme simplifiée." which means, translated : "When only one instruction is used in the section Then and in the section Else, the sequence can be written on one single line : If expr1 Then instruction1v Else instruction1f Please note the absence of End If in this simplified usage" Therefore I still consider this as a bug. I believe you are correct. In my recent work on making the trunk test suites standalone to run against other branches like AOO41X I discovered some other bug fixes that were applied to trunk and AOO42X but never back ported to AOO41X. Two examples I put in a PR-150 [1]. One of which related to variable names in single-line if statements. I tested your example against that build but it isn't fixed by it but I believe I found the patch that fixed your bug in trunk [2]. Issue 126272 [3] is listed in Bugzilla with a target milestone of 4.2. I think this needs a more general discussion on dev@ about how much we should change API's in 4.1.X. Which I intended to do anyway before merging my PR-150. Thanks for pointing this out! [1]https://github.com/apache/openoffice/pull/150 [2] https://github.com/apache/openoffice/commit/07396187f6055b1e7cffa86f38cc88b274dfb1d6 [3]https://bz.apache.org/ooo/show_bug.cgi?id=126272 I think this fix [2] should be cherry-picked to AOO41X. BTW: The target milestone 4.2.0 was trunk at that time. Later we made trunk 4.5.0 and branched 4.2.0, but the milestones were not updated. Yes, I just want to make sure it wasn't intentional to leave this one and a few other changes the the Basic macros out of the 4.1 line due to not wanting to change API or code behavior. I will create a PR for it or maybe just add it to the other one I've got open since they are all small and bring a discussion on dev@. Then if we agree it's okay I'll pull them in. Best regards, Carl Regards, Matthias Best regards, Carl With kind regards, Lucien Le 6/06/22 à 13:32, Regina Henschel a écrit : Hi Lucien, Lucien Mathay schrieb am 06.06.2022 um 10:42: Hello, I would like to report the following bug : in the macros when a line containing "if ... then ... else" is followed by a comment on the same line, the compiler fails. Example : Function test() dim a as long, b as long a=0: b=0 if a = b then a=1 else a=2 'test b=1 call msgbox b End Function The if-statement misses endif. Kind regards, Regina - To unsubscribe,e-mail:qa-unsubscr.
Re: bug report strange behaviour usertypes
Hi All, On 6/10/22 9:30 AM, Carl Marcum wrote: Hi Lucien, On 6/10/22 9:05 AM, Lucien Mathay wrote: Hi, I am sorry to seek help and at the same time report a strange behaviour, for a problem on which I can not find the origin. I have a strange behaviour in an OOBasic program, and to make it simple I pruned down the question to the 12 lines of program which are displayed here : option explicit Type ZONEDIALOG hauteur As Long largeur As Long End Type Dim ZDstack(0 To 2) As ZONEDIALOG Function Auto_Open() dim quoi as long quoi = 2 'const_xyz msgbox "OK" End Function The strange behaviour is as follows : * when executing this program, the message "Ok" comes up as expected, everything is fine and there is no error. * However now, consider the constant "2" at line 'quoi = 2' : if you replace this constant "2" by "const_xyz" (which is obviously undefined), observe what happens during thenext executions : o first execution brings up the message "Ok" : the error was not detected, although option explicit is active ... but that is not yet the biggest problem o executing a second time brings up "Basic execution error 9 : index out of the assigned range" at the line 'Dim ZDStack' * Now if reverting back to the constant "2" by removing "const_xyz" and putting the constant "2" in place again, it is also abnormal : o first execution shows "Ok" o following executions bring up "Basic execution error 9 : index out of the assigned range" at the line 'Dim ZDStack' There is however a background to this behaviour : this file is issued from a full program showing this problem by removing all the unnecessary functions and sheets out of the program. If this small portion of code is copied to a fresh calc file, the strange behaviour does not show up. Therefore, I suspect the behaviour to be caused by something else than just the code ; this is why I appended the file to this mail, for you to be able to debug. I compared the sections of the file with the xml sections of a fresh document, and I found differences only in content.xml, settings.xml and styles.xml, but nothing that could explain me why this behaviour. If a charitable person could analyse this file, it would help me getting running the full program from which it is issued ... and it would probably expose a new bug in OO. It won't be an easy job however I believe, therefore I am really thankful in advance ! Lucien PS: I tried the file on two versions of OO and one LibreOffice, it does not make any difference. What versions of AOO and LO have you tested on and also what OS? Thanks, Carl I got reply this off-list so I'll add it here: OO on 4.1.6 and 4.1.12, installed on Windows XP and LibreOffice Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.11 Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: bug report strange behaviour usertypes
Hi Lucien, On 6/10/22 9:05 AM, Lucien Mathay wrote: Hi, I am sorry to seek help and at the same time report a strange behaviour, for a problem on which I can not find the origin. I have a strange behaviour in an OOBasic program, and to make it simple I pruned down the question to the 12 lines of program which are displayed here : option explicit Type ZONEDIALOG hauteur As Long largeur As Long End Type Dim ZDstack(0 To 2) As ZONEDIALOG Function Auto_Open() dim quoi as long quoi = 2 'const_xyz msgbox "OK" End Function The strange behaviour is as follows : * when executing this program, the message "Ok" comes up as expected, everything is fine and there is no error. * However now, consider the constant "2" at line 'quoi = 2' : if you replace this constant "2" by "const_xyz" (which is obviously undefined), observe what happens during thenext executions : o first execution brings up the message "Ok" : the error was not detected, although option explicit is active ... but that is not yet the biggest problem o executing a second time brings up "Basic execution error 9 : index out of the assigned range" at the line 'Dim ZDStack' * Now if reverting back to the constant "2" by removing "const_xyz" and putting the constant "2" in place again, it is also abnormal : o first execution shows "Ok" o following executions bring up "Basic execution error 9 : index out of the assigned range" at the line 'Dim ZDStack' There is however a background to this behaviour : this file is issued from a full program showing this problem by removing all the unnecessary functions and sheets out of the program. If this small portion of code is copied to a fresh calc file, the strange behaviour does not show up. Therefore, I suspect the behaviour to be caused by something else than just the code ; this is why I appended the file to this mail, for you to be able to debug. I compared the sections of the file with the xml sections of a fresh document, and I found differences only in content.xml, settings.xml and styles.xml, but nothing that could explain me why this behaviour. If a charitable person could analyse this file, it would help me getting running the full program from which it is issued ... and it would probably expose a new bug in OO. It won't be an easy job however I believe, therefore I am really thankful in advance ! Lucien PS: I tried the file on two versions of OO and one LibreOffice, it does not make any difference. What versions of AOO and LO have you tested on and also what OS? Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bug report : comment after "if ... then ... else"
Hi Matthias, On 6/7/22 6:53 AM, Matthias Seidel wrote: Hi Carl, Am 07.06.22 um 00:59 schrieb Carl Marcum: Hi Lucien, On 6/6/22 12:51 PM, Lucien Mathay wrote: Thank you Regina, but if I add an 'endif' at the end of the line ( " if a = b then a=1 Else a=2 endif 'test "), the compiler fails with the message "Syntax error : unexpectes symbol : End If". Furthermore, the book from "OpenOffice .org Macros OoOffice et Apis" from Bernard Marcelly and Laurent Goddard states p.118 : "Lorsqu’une seule instruction suffit dans la partie Then et dans la partie Else, la séquence peut s’écrire sur une seule ligne : If expr1 Then instruction1v Else instruction1f Notez l’absence du End If dans cette forme simplifiée." which means, translated : "When only one instruction is used in the section Then and in the section Else, the sequence can be written on one single line : If expr1 Then instruction1v Else instruction1f Please note the absence of End If in this simplified usage" Therefore I still consider this as a bug. I believe you are correct. In my recent work on making the trunk test suites standalone to run against other branches like AOO41X I discovered some other bug fixes that were applied to trunk and AOO42X but never back ported to AOO41X. Two examples I put in a PR-150 [1]. One of which related to variable names in single-line if statements. I tested your example against that build but it isn't fixed by it but I believe I found the patch that fixed your bug in trunk [2]. Issue 126272 [3] is listed in Bugzilla with a target milestone of 4.2. I think this needs a more general discussion on dev@ about how much we should change API's in 4.1.X. Which I intended to do anyway before merging my PR-150. Thanks for pointing this out! [1] https://github.com/apache/openoffice/pull/150 [2] https://github.com/apache/openoffice/commit/07396187f6055b1e7cffa86f38cc88b274dfb1d6 [3] https://bz.apache.org/ooo/show_bug.cgi?id=126272 I think this fix [2] should be cherry-picked to AOO41X. BTW: The target milestone 4.2.0 was trunk at that time. Later we made trunk 4.5.0 and branched 4.2.0, but the milestones were not updated. Yes, I just want to make sure it wasn't intentional to leave this one and a few other changes the the Basic macros out of the 4.1 line due to not wanting to change API or code behavior. I will create a PR for it or maybe just add it to the other one I've got open since they are all small and bring a discussion on dev@. Then if we agree it's okay I'll pull them in. Best regards, Carl Regards, Matthias Best regards, Carl With kind regards, Lucien Le 6/06/22 à 13:32, Regina Henschel a écrit : Hi Lucien, Lucien Mathay schrieb am 06.06.2022 um 10:42: Hello, I would like to report the following bug : in the macros when a line containing "if ... then ... else" is followed by a comment on the same line, the compiler fails. Example : Function test() dim a as long, b as long a=0: b=0 if a = b then a=1 else a=2 'test b=1 call msgbox b End Function The if-statement misses endif. Kind regards, Regina - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bug report : comment after "if ... then ... else"
Hi Lucien, On 6/6/22 12:51 PM, Lucien Mathay wrote: Thank you Regina, but if I add an 'endif' at the end of the line ( " if a = b then a=1 Else a=2 endif 'test "), the compiler fails with the message "Syntax error : unexpectes symbol : End If". Furthermore, the book from "OpenOffice .org Macros OoOffice et Apis" from Bernard Marcelly and Laurent Goddard states p.118 : "Lorsqu’une seule instruction suffit dans la partie Then et dans la partie Else, la séquence peut s’écrire sur une seule ligne : If expr1 Then instruction1v Else instruction1f Notez l’absence du End If dans cette forme simplifiée." which means, translated : "When only one instruction is used in the section Then and in the section Else, the sequence can be written on one single line : If expr1 Then instruction1v Else instruction1f Please note the absence of End If in this simplified usage" Therefore I still consider this as a bug. I believe you are correct. In my recent work on making the trunk test suites standalone to run against other branches like AOO41X I discovered some other bug fixes that were applied to trunk and AOO42X but never back ported to AOO41X. Two examples I put in a PR-150 [1]. One of which related to variable names in single-line if statements. I tested your example against that build but it isn't fixed by it but I believe I found the patch that fixed your bug in trunk [2]. Issue 126272 [3] is listed in Bugzilla with a target milestone of 4.2. I think this needs a more general discussion on dev@ about how much we should change API's in 4.1.X. Which I intended to do anyway before merging my PR-150. Thanks for pointing this out! [1] https://github.com/apache/openoffice/pull/150 [2] https://github.com/apache/openoffice/commit/07396187f6055b1e7cffa86f38cc88b274dfb1d6 [3] https://bz.apache.org/ooo/show_bug.cgi?id=126272 Best regards, Carl With kind regards, Lucien Le 6/06/22 à 13:32, Regina Henschel a écrit : Hi Lucien, Lucien Mathay schrieb am 06.06.2022 um 10:42: Hello, I would like to report the following bug : in the macros when a line containing "if ... then ... else" is followed by a comment on the same line, the compiler fails. Example : Function test() dim a as long, b as long a=0: b=0 if a = b then a=1 else a=2 'test b=1 call msgbox b End Function The if-statement misses endif. Kind regards, Regina - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: New QA Volunteer
Hi João Paulo, On 2/21/22 3:22 PM, João Paulo Carvalho wrote: Hi! My name is João Paulo, I'm Brazilian and I study computer science. I have been using and recommending the Apache Open Office application for some time. I would love to contribute to the testing and QA community. Regards, João Paulo Carvalho. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org Welcome to the project. Are you looking to do manual testing or something like running or even working on the automated tests which are Java JUnit 4 based? Have you how found the QA section of our wiki? Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
[QA AUTOMATION] Standalone Tests now available in standalone-test branch
Hi All, cc: dev@ Just an FYI on the status of my work on allowing the automated test suites to compile and run tests without a working AOO build environment. I've started a new branch standalone-test [1] with a README file explaining the usage. So far I've been able to run tests on CentOS 7 and Windows 10. It would be great if others could try other platforms as well. All that's required is Ant and Java. I should probably add that to the README somewhere :) I'd also like feedback on if this causes any unintended consequences for those that may use the tests as they are today. Again, the big difference is current trunk, AOO41X, AOO42X, etc tests require having first ran a build and the test compile had dependencies on the Java UNO jars and tools like javamaker, regmerge, and idlc where I've changed this branch to use the office to be tested for the dependencies. This also means it requires a SDK be installed in the office under test's root directory. I think this is a good trade off that allows more people to run tests and work on them also. This and more is in the test/README. Please let me know if you have any questions or trouble testing. [1] https://github.com/cbmarcum/openoffice/tree/standalone-test/test Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: rework the automated tests to not require an office build first
Hi Keith, On 6/20/21 9:10 PM, Keith N. McKenna wrote: On 2021-06-12 at 9:13, Carl Marcum wrote: Hi All, cc'd qa@ I think it would be good to rework the test framework to not require having just built the office. I believe that you are right. I know for myself, I do not have the capacity to be able to build on Windows and cannot run the automated tests. Currently, to compile and run the tests, there are dependencies on environment settings created and files built into main/solver/. Mostly things like idlc, regmerge, and javamaker etc. and the UNO jar files. All these file dependencies are also available in either the office that would be under test or the SDK. I think it would be a benefit for QA and open the use and development of automated tests to testers and developers that don't also have a AOO build environment. It would definitely be a help to QA. If a volunteer does not have the capacity to build, the most they can do is to confirm that a particular bug exists with their OS, and then verify that a build with a specific patch fixed the problem. With the ability to run the automated tests, individual volunteers could contribute more than just confirming and verifying particular bugs. For instance I can run the test suite against Linux where I have a build env but not on Windows where I don't. The one big thing about this would be it would require a tester to have the SDK installed in the office under test. I think this is a much lower bar than building the office to get them. Does anyone have an opinion one way or the other? I believe that it would be a very good idea Regards Keith I'm glad you agree. I've made good progress on this and I can run the Build Verification tests on Windows 10 without building the office now. It seems the tests themselves need some work but that's the point. I've been able to fix tests on Linux but not Windows. Some tests randomly pass and fail (flaky tests). A lot can be fixed by adding pauses in the test code to let the UI catch up. I'll probably submit a PR in the next few days after I've tested some more. Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
rework the automated tests to not require an office build first
Hi All, cc'd qa@ I think it would be good to rework the test framework to not require having just built the office. Currently, to compile and run the tests, there are dependencies on environment settings created and files built into main/solver/. Mostly things like idlc, regmerge, and javamaker etc. and the UNO jar files. All these file dependencies are also available in either the office that would be under test or the SDK. I think it would be a benefit for QA and open the use and development of automated tests to testers and developers that don't also have a AOO build environment. For instance I can run the test suite against Linux where I have a build env but not on Windows where I don't. The one big thing about this would be it would require a tester to have the SDK installed in the office under test. I think this is a much lower bar than building the office to get them. Does anyone have an opinion one way or the other? Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: JUnit update from 4.10 to 4.13.2 in test automation
Hi All, adding cc. dev@ On 5/31/21 3:05 PM, Carl Marcum wrote: Hi All, Just an FYI I've been working on updating the JUnit library used in the test suites for trunk. Our current 4.10 is ten years old. I'm doing this in two steps. First step was the library update to 4.12 in commit 069226d [1]. The only effect of this is users that have ran the automated tests and have a test/lib folder need to delete the junit.jar before compiling the tests again and you will get the 4.12 jar and also hamcrest 2.2 as well. A change in 4.11 was the need to separately include a hamcrest dependency. Now that is integrated I've submitted PR-131 [2] to go to JUnit 4.13.2 which is the latest in the JUnit 4 series. This required class changes due to changes in JUnit 4.13 which is why I chose to split it up. BTW, JUnit 5 is the new rewrite of this library but it has a Java 8 dependency and a lot of changes to the API to it's not something I'm looking at currently. However just these updates open up many improvements that can be made in the tests especially the parameterized ones. *** Anyone who compiles the test suite needs to delete or empty the /test/lib directory before compiling to get the correct junit.jar and the new hamcrest.jar required. *** This will need done again after PR-131 is merged. I'll post a note here after it's integrated. [1] https://github.com/apache/openoffice/commit/069226d344055623fb554fac841132ecefce563a [2] https://github.com/apache/openoffice/pull/131 The test automation has been updated in trunk and AOO42X to use JUnit 4.13.2 (latest JUnit 4) and now includes Hamcrest 2.2 (latest). Anyone who runs the automated test suites will need to remove the junit.jar from /test/lib and you should get the new jars downloaded next time you compile the tests. Please let me know if you have any questions. Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
JUnit update from 4.10 to 4.13.2 in test automation
Hi All, Just an FYI I've been working on updating the JUnit library used in the test suites for trunk. Our current 4.10 is ten years old. I'm doing this in two steps. First step was the library update to 4.12 in commit 069226d [1]. The only effect of this is users that have ran the automated tests and have a test/lib folder need to delete the junit.jar before compiling the tests again and you will get the 4.12 jar and also hamcrest 2.2 as well. A change in 4.11 was the need to separately include a hamcrest dependency. Now that is integrated I've submitted PR-131 [2] to go to JUnit 4.13.2 which is the latest in the JUnit 4 series. This required class changes due to changes in JUnit 4.13 which is why I chose to split it up. BTW, JUnit 5 is the new rewrite of this library but it has a Java 8 dependency and a lot of changes to the API to it's not something I'm looking at currently. However just these updates open up many improvements that can be made in the tests especially the parameterized ones. *** Anyone who compiles the test suite needs to delete or empty the /test/lib directory before compiling to get the correct junit.jar and the new hamcrest.jar required. *** This will need done again after PR-131 is merged. I'll post a note here after it's integrated. [1] https://github.com/apache/openoffice/commit/069226d344055623fb554fac841132ecefce563a [2] https://github.com/apache/openoffice/pull/131 - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
[LAZY CONSENSUS] Merge PR-125 into 4.1.X branch
Hi All, Since this is a rather large pull request based on many commits I want to use lazy consensus here. This PR-125 [1] is based on a lot of work by Damjan and a few others on fixing flaky automated tests and other improvements that could be back-ported to the 4.1 line. Also included is a fix for the 3 FVT tests that hang waiting on the test runner to accept a dialog. As I run a lot of these tests I think these are useful to the 4.1 line. Everything is below the test directory so it should not affect any builds. Unless there are objections I plan to pull these in to the 4.1.X branch after 72 hours. [1] https://github.com/apache/openoffice/pull/125 Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: New QA Volunteer
Welcome Marko, Do you subscribe to the dev@ list also? There is currently a VOTE in progress on a release candidate that we are testing now that is running until tomorrow I believe. If that's too soon there is other testing to be done soon as well as other QA things to do. Anyway welcome and let us know if you have any questions. Thanks, Carl On 1/20/21 12:52 PM, Marko N wrote: Hi, I'm Marko Nikolic from Belgrade. My background is in Finance and Logistics, but I am looking to transition into QA and believe I would make a great fit for this team as I've done few courses on manual software testing recently. Hope to start collaborating soon. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
[QA] Verification Test Report macro
Hi All, For those that run the automated tests after a build. I wrote a Groovy macro to import the XML results from JUnit into Calc as another option besides the HTML reports. A short video on it's use and where to get it. https://youtu.be/mpC6gNUuWCY Please let me know if you have any questions. Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: QA Automated Test coverage
(Originally posted to dev and I forgot to cc this list) Hi Damjan, On 10/28/20 12:21 AM, Damjan Jovanovic wrote: On Sat, Oct 24, 2020 at 8:14 PM Carl Marcum wrote: Hi All, I've been testing builds with the automated BVT and FVT tests lately. I have a few questions: 1. Is there anything documented about how much coverage these tests provide vs.functionality? 2. Is there yet a place to list new cases it would good to add test for? I think there is a lot that could be done in this area to attract new contributors if we had a place to work from. Both in documenting and work on some flaky tests that I've run into. I'm willing to put some effort into this, both organizing and developing. Hi Carl Thank you for helping with the tests. I wrote a good email summarizing the different tests we have some years ago, please see https://lists.apache.org/thread.html/bb1851b82ba009d2cefdf5af9997099b6fdfb04bddac3753172f2698%401459253891%40%3Cdev.openoffice.apache.org%3E Some things changed since then, eg. the smoketest location moved. There are a few other emails too, search for them. I also did some test fixes to bvt/fvt and others at various times. This year I learned quite a lot about them. For example many tests fail because they expect features that the .DOC file format cannot provide (such as strikeout styles unique to .ODT), there were timeouts, registry modifications had to be enabled to fix a test, confirmation dialogs that hang the tests, a 2048 byte limit in FreeBSD's "ps" was causing a pid lookup to fail, java.util.Calendar was being used incorrectly, etc. I fixed some of these, but others remain. Understanding why the .DOC tests fail requires understanding the .DOC file format, so fixing those tests isn't easy. Look through the Git log, I wrote pretty descriptive commit messages. One thing I didn't mention in that email is the thousands of unused tests we have in main/qadevOOo, but they seem difficult to set up, and use a custom test framework, not JUnit. They have a complex architecture, with some code implementing UNO components and some code testing them. There might even be code missing for some of them. There's a mixture of Java and StarBasic tests there, with much duplication - were they first written in one language then semi-ported to another? Anyway I can't help much at the moment, but good luck and let us know how it goes. Damjan Thanks for the great information and the email link. I saw some of commits on some of the flaky tests where you added a sleep before checking the results. I think there are more of these but I was holding off thinking it would be low hanging fruit for a new volunteer :) But I'll take care if it if not. I liked Patricia's suggestion of a page for this work. I'll try to find if one was started and if not start one. I'll look into testing the OOO_SUBSEQUENT_TESTS flag also. It seems building the bvt/fvt tests using ant require an office to have been built and use idlc and the uno jars from solver like: test/smoketestdoc.build.xml imports main/ant.properties which includes OUTDIR=/openoffice/main/solver/450/unxlngx6.pro OUTDIR is used in the path to idlc and the build fails if I've cleaned the office build. I think it would be good if we could use idlc and uno jars from whichever office is under test so you don't need a build environment necessarily but I'm still looking at the implications of that. Please let me know if you have an opinion on that since you've dug a lot deeper. Looking ahead I see new tools like testcontainers [1] you can use in maven and gradle builds for spinning up and disposing of databases, servers, and other things for integration tests. This looks like fertile ground for some work :) [1] https://www.testcontainers.org/ Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [QA REPORT] BVT test results for Debian / Ubuntu error on AOO418-RC2
Hi Matthias, On 10/25/20 1:30 PM, Matthias Seidel wrote: Hi Carl, It would be interesting to run these tests on a build that does not show the error message. Regards, Matthias Next one without the error I will report on. Thanks, Carl Am 25.10.20 um 16:57 schrieb Carl Marcum: cc dev@ I thought I'd try out the tests on Jim's test9 build from last night that had the General Error thrown to see if it got picked up and it did. Sometimes I'll get a few false failures or errors on different runs (working on getting a list of them to fix) but it's usually 0 -2 so I'm pretty confident most of these are legitimate. This is filtered for only the errors.. Class Name Method Name Error bvt.gui.BasicFunctionTest smokeTest ID:SW_HID_EDIT_WIN - Window/Control could not be found bvt.gui.BasicFunctionTest testExportAsPDF SW_HID_EDIT_WIN is not found! bvt.gui.BasicFunctionTest testRunMacro SC_HID_SC_WIN_GRIDWIN is not found! bvt.gui.BasicFunctionTest testFind SW_HID_EDIT_WIN is not found! bvt.gui.BasicFunctionTest testFindFormulasAndValues SC_HID_SC_WIN_GRIDWIN is not found! bvt.gui.BasicFunctionTest testSort SC_HID_SC_WIN_GRIDWIN is not found! bvt.gui.FileTypeTest testSaveNewODT Timeout to execute the dispatch! bvt.gui.FileTypeTest testSaveNewSXW SW_HID_EDIT_WIN is not found! bvt.gui.FileTypeTest testSaveNewOTT Timeout to execute the dispatch! bvt.gui.FileTypeTest testSaveNewSTW SW_HID_EDIT_WIN is not found! bvt.gui.FileTypeTest testSaveNewODS SC_HID_SC_WIN_GRIDWIN is not found! bvt.gui.FileTypeTest testSaveNewOTS SC_HID_SC_WIN_GRIDWIN is not found! Please let me know if you have any questions. Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
[QA REPORT] BVT test results for Debian / Ubuntu error on AOO418-RC2
cc dev@ I thought I'd try out the tests on Jim's test9 build from last night that had the General Error thrown to see if it got picked up and it did. Sometimes I'll get a few false failures or errors on different runs (working on getting a list of them to fix) but it's usually 0 -2 so I'm pretty confident most of these are legitimate. This is filtered for only the errors.. Class Name Method Name Error bvt.gui.BasicFunctionTest smokeTest ID:SW_HID_EDIT_WIN - Window/Control could not be found bvt.gui.BasicFunctionTest testExportAsPDF SW_HID_EDIT_WIN is not found! bvt.gui.BasicFunctionTest testRunMacro SC_HID_SC_WIN_GRIDWIN is not found! bvt.gui.BasicFunctionTest testFind SW_HID_EDIT_WIN is not found! bvt.gui.BasicFunctionTest testFindFormulasAndValues SC_HID_SC_WIN_GRIDWIN is not found! bvt.gui.BasicFunctionTest testSort SC_HID_SC_WIN_GRIDWIN is not found! bvt.gui.FileTypeTest testSaveNewODT Timeout to execute the dispatch! bvt.gui.FileTypeTest testSaveNewSXW SW_HID_EDIT_WIN is not found! bvt.gui.FileTypeTest testSaveNewOTT Timeout to execute the dispatch! bvt.gui.FileTypeTest testSaveNewSTW SW_HID_EDIT_WIN is not found! bvt.gui.FileTypeTest testSaveNewODS SC_HID_SC_WIN_GRIDWIN is not found! bvt.gui.FileTypeTest testSaveNewOTS SC_HID_SC_WIN_GRIDWIN is not found! Please let me know if you have any questions. Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
QA Automated Test coverage
Hi All, I've been testing builds with the automated BVT and FVT tests lately. I have a few questions: 1. Is there anything documented about how much coverage these tests provide vs.functionality? 2. Is there yet a place to list new cases it would good to add test for? I think there is a lot that could be done in this area to attract new contributors if we had a place to work from. Both in documenting and work on some flaky tests that I've run into. I'm willing to put some effort into this, both organizing and developing. Slightly off topic is the QA Intro page [1] discusses TestLink which I don't think we use anymore and migrated the tests onto the wiki [2]. But this list seems to describe the automated tests. At least some that I've looked at. Manual Tests (it says outdated) are here [3]. Link to the Test Case Management is also a 404. [1] https://openoffice.apache.org/orientation/intro-qa.html [2] https://www.openoffice.org/qa/testcase/ManualTesting/ [3] https://www.openoffice.org/qa/testcase/index.html Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Testing: Is there any interest in the old TestLink system and/or test cases?
On 01/31/2018 02:04 PM, Kay Schenk wrote: On Wed, Jan 31, 2018 at 8:27 AM, Kay Schenk <kay.sch...@gmail.com> wrote: On Tue, Jan 30, 2018 at 3:37 PM, Carl Marcum <cmar...@apache.org> wrote: On 01/30/2018 05:47 PM, Kay Schenk wrote: As I previously posted, the old TestLink instance is still alive but NOT well on: http://aootesting.adfinis-sygroup.org/login.php?note=expired referenced from the Apache OpenOffice QA information at: https://openoffice.apache.org/orientation/intro-qa.html * Is there any interest in revising TestLink completely? This would require contacting adfinish-sygroup.org to establish a new admin for our TestLink instance who would then be responsible for general oversight of this platform including adding users, etc. Recently, I setup a guest account and had a look around. It seems SOME tests are continuing to be run automatically (bvt, etc.), but they are referencing the old 4.0.x series and I have no knowledge of how any of this is setup. * Is there any interest in salvaging the existing test cases (manual write-ups) from the TestLink system and porting them to the AOO svn tree under "/test" with a new sub-are named "manual_tests" or something similar. The manual test cases most recently pertained to 4.0.x but I'm sure they could continue to be used for the 4.1.x and 4.2.x series. Hi Kay, I hope to one day soon try my hand at some QA. I just looked around TestLink and it looks interesting. Is this web service donated to the project? Is there a risk of loosing this information somehow? Thanks, Carl Carl, I don't really know the answer to your first question about donation of the Testlink platform to AOO. Yuzhen Fan, a current committer and PMC member, seems to be the last administrator of Testlink with the Adfinis group, and may have some answers on this. On the second question. Although there are some test cases ported to the AOO user wiki, we would be wise to collect up the test cases on the Testlink platform as soon as we can for safekeeping. Previously, I was only involved in QA as a tester. A slight clarification on this response. The TestLink instance on http://aootesting.adfinis-sygroup.org/ was setup and administered by members of the QA area initially, all PMC members. Some AOO committers involved in QA, myself included, had administrative capabilities within the AOO TestLink instance but not the actual instance itself. Hi Kay, Thanks for the clarification. I agree that having important information such as this only outside of Apache controlled assets is a risk. I would be good if they have a way to export them so we at least maintain a copy. I can also see the benefit of the service being maintained as long as it's available to us. Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Testing: Is there any interest in the old TestLink system and/or test cases?
On 01/30/2018 05:47 PM, Kay Schenk wrote: As I previously posted, the old TestLink instance is still alive but NOT well on: http://aootesting.adfinis-sygroup.org/login.php?note=expired referenced from the Apache OpenOffice QA information at: https://openoffice.apache.org/orientation/intro-qa.html * Is there any interest in revising TestLink completely? This would require contacting adfinish-sygroup.org to establish a new admin for our TestLink instance who would then be responsible for general oversight of this platform including adding users, etc. Recently, I setup a guest account and had a look around. It seems SOME tests are continuing to be run automatically (bvt, etc.), but they are referencing the old 4.0.x series and I have no knowledge of how any of this is setup. * Is there any interest in salvaging the existing test cases (manual write-ups) from the TestLink system and porting them to the AOO svn tree under "/test" with a new sub-are named "manual_tests" or something similar. The manual test cases most recently pertained to 4.0.x but I'm sure they could continue to be used for the 4.1.x and 4.2.x series. Hi Kay, I hope to one day soon try my hand at some QA. I just looked around TestLink and it looks interesting. Is this web service donated to the project? Is there a risk of loosing this information somehow? Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
On 08/05/2016 12:28 PM, Dennis E. Hamilton wrote: For tracking the [TESTING] of the 4.1.2-patch1 binary for windows, I have created task Issue 127065, <https://bz.apache.org/ooo/show_bug.cgi?id=127065>. Comment 7 there already speaks to the untrusted identification situation. I am adding an abridged version of this message from Carl with the part relevant to certificate trust. Note that most of us who have worked on 4.1.2-patch1 and provided digital signatures will find that identity will be reported as untrusted based on the Web-of-Trust technique PGP software uses. We can, of course, verify the fingerprints and Apache account identity and certify each other. That will change the status for those of us in this particular circle but not necessarily for anyone who does not already trust the identification of enough of us. I don't think there is any way to get into this in our README files. However, this is useful for any future contributions we might make to the page at <http://www.apache.org/dev/release-signing.html> or anything supplemental that is oriented to the users of Apache OpenOffice and their particular range of skills. -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Friday, August 5, 2016 03:30 To: d...@openoffice.apache.org Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows On 08/04/2016 06:52 PM, Marcus wrote: Am 08/05/2016 12:26 AM, schrieb Kay Schenk: On 08/04/2016 02:21 PM, Marcus wrote: [ ... ] * apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.asc I don't know if this is OK or still bad: gpg --verify apache-openoffice-4.1.2-patch1-apply-Win_x86.zip.asc apache-openoffice-4.1.2-patch1-apply-Win_x86.zip gpg: Signature made Tue 02 Aug 2016 06:24:08 AM CEST using RSA key ID D456628A gpg: Good signature from "keybase.io/orcmid (confirmed identifier) <orc...@keybase.io>" gpg: aka "orcmid (Dennis E. Hamilton)<orc...@msn.com>" gpg: aka "orcmid Apache (code signing)<orc...@apache.org>" gpg: aka "Dennis E. Hamilton (orcmid) <dennis.hamil...@acm.org>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. I get this on sig checks also. There's probably a step we're missing to specify "trust" locally. See: http://www.apache.org/dev/release-signing.html signing Dennis' key locally worked for me. On Linux I use: gpg --default-key 9553BF9A --sign-key D456628A If the key you want to sign it with is already the default key you can omit the "--default-key 9553BF9A" part. Sometimes you may have to prefix the ID's with "0x" to denote hex. If you trust this is Dennis' key you can send his key back with your sig now attached and it will have more trust. gpg --send-key 0xD456628A If a few people do it the warning should go away. Web-of-trust :) Carl [orcmid] The warning will go away for us who have created a mutual Web-of-Trust but it won't help those who are not in that circle or have not somehow determined to trust in it themselves. This is still useful advice about how to do it. PS: I don't think the dist-level KEYS file is updated automatically, so the release KEYS set needs to be refreshed to work. (We can check that by waiting for a while to see if Carl's trust of Dennis's key shows up.) Dennis, Yes I think I over simplified that. Thanks for clarifying. Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Smoke Test to run on a built office
Hi all, Are there other automated smoke test macros or scripts other than noted below that can be ran on a built office to test basic functionality and make sure nothing major is broken? I found this wiki page [1] that references a sxw document that contains macros and will display a report but I'm not sure how recent it is due to the file extension. The file is smoketestdoc.sxw in main/smoketestdoc/unxlngx6.pro/misc/zip of a build. [1] https://wiki.openoffice.org/wiki/SmokeTest Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [DISCUSS] Cleanup needed for RESOLVED-FIXED issues
On 04/06/2016 06:43 PM, Kay Schenk wrote: I think typically the process for RESOLVED-FIXED (those issues that were fixed by some kind of code change to /trunk) issues is to: * commit the change to a release build * once the release build is out for testing, check that the bug is fixed, and use RESOLVED-VERFIED, to verify the fix, then * CLOSE the issue Recently, when I was looking at some issues that we'd targeted for 4.1.2, I came upon a number that had been RESOLVED-FIXED, but some had been committed to a release and some had not. For those that had, I skipped the RESOLVED-VERIFIED step and just closed them. Currently, I feel we could use some additional help with a) closing out old issues that have been ported to a release, and b) resetting the Target Release information for those issues that have been fixed but have not been "released". The following query only looks at RESOLVED-FIXED issues since 2011-01-01 https://bz.apache.org/ooo/buglist.cgi?bug_status=RESOLVED=resolution=2011-01-01=Now=Fixed=0=priority%2Cbug_severity_format=advanced=FIXED=FIXED_WITHOUT_CODE A warning -- unless you can see an SVN commit clearly stating that the fix has been ported to one of our existing releases, it may take a bit of investigation into the release branch area to determine this. release branch area-- http://svn.apache.org/viewvc/openoffice/branches/ Our new resolution of FIXED_WITHOUT_CODE should result in CLOSING without any further investigation. Thoughts on undertaking this cleanup? Off topic... I started going through some of the NetBeans related issues last evening. Most are very old. In some cases I found the proposed code changes had been made but I couldn't tell when because it was prior to the Apache migration. I RESOLVED-OBSOLETE very old ones I could not verify and RESOLVED-FIXED ones I could. Thanks, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
