all our old OOo api tests are written in java: They are hard to debug and a lot of them are disabled. Some work has been done for calc to convert some of the interfaces but there is still a lot of work to do. The test code for the interfaces is in test/inc/test/ and test/source/ and the old java code is in qaDevOOo. The code that then tests the interface implementation inherits from the code in test/ and will be in sc, sw, sd, dbaccess or any other module. For the already transfered tests see sc/qa/extras Most of the transformation can be done quite easily, if not please ask.
Das Dreifach-Date
Please don't remove whiteboard entries from an easy hack that have been added by the mentoring developer.
I'd be willing to contribute towards the unit tests. I have industry experience working with Google test so I have some experience with unit testing and I'm familiar with both Java and C++. If someone could mail me and get me up to speed on what needs to be done then I'd definitely consider giving it a go.
Hey David, sorry that it took me a bit to come back to your question but we were in a bit of release hurry the last days ;) As I mentioned in my first comment we have inherited quite a lof of java based API tests that in the end test c++ code. This is horrible to debug and quite slow and we have actually a framework to do the same in c++ for a bit more than 1,5 years now. The old java based tests can be found in qaDevOOo/ The code is divided between the code that is necessary to setUp the test and the test for an interface. This corresponds to our API definition in offapi as the part for the service definition and the interface definition. You can find some of the transformed tests in test/ and sc/qa/extras/ Inside test/ you can find the code to test an interface and in sc/qa/extras/ you can find the code that is necessary to setUp a test. if you search for the name of the file in the code in sc you normally also find the interface/service implementation inside sc/source/ui/unoobj/ If you want to start with some tests that have been disabled you can look into http://opengrok.libreoffice.org/xref/core/sc/qa/unoapi/knownissues.xcl You can also see a list of java tests that have been already converted. Please ignore the accessibility tests. Right now they are in a really bad shape and we have not yet decided what will happen to the accessibility code in the future. Please don't hesitate to ask for more information.
Hi Markus, Thanks for the reply. I will look into this on Monday as I have a few spare hours. The problem is my schedule is tight as I have final year projects to do at the moment and seeing as this is my first time contributing to an open source project it might take a few weeks to do this, I assume that's ok? if that is ok then I will start cracking into them come Monday. I've done a fairly extensive suite of unit tests with Google test. So other frameworks should work similarly. At the moment I'm looking at the coding standards to try and familiarise myself with the standards. If you feel I should know more information do please let me know.
Hi, I am a slightly advanced beginner (I have just finished my first "bigger" project. It was a card game similar to MauMau) and familier with C++ and Java. I motivated to learn unit testing. Could you mail me what needs to be done and where I could start? Thank you.
Hi Markus, can you please add some more details for beginners to start working on this easy ack? :)
I am quite interested in investigating this bug. Can you please fill me in on where to start? This is my first time doing open source contribution, and I am a senior of Computer Science at Portland State University. Thanks! Sean Walsh
So I'll try to add a few more details but I'm currently on vacation. So please excuse if it is not in as much detail as it should be. Currently our api test code is at qadevooo/tests/java/ and there in there in the folders IFC and mod. The implementation is divided between these two folders to represent our two parts of the api implementations. The sender IFC part is for the interface definition that is represented in our api through the IDL files in offapi and can be found at api.LibreOffice.org. the mod part is for the actual implementation that implements several interfaces. We have a similar structure for the c++ tests. The test code for the interfaces can be found in test/ and the code for the implementations for calc in sc/qa/extras. Each file in sc/qa/extras represents one implementation file and is one cppunit test that is registered by a make file in sc/ and in sc/module_sc.mk. the new tests just make it explicit which interfaces are tested while it is implicitly done in the old java tests by querying for all interfaces the object provides. So we now need a two step process to convert old tests. First convert the interface test code and implement it in test/ and secondly convert or better write a clean new implementation for the api implementation. The c++ implementation should however try to make the tests better by using the assertion macros that are provided by cppunit, make explicit what was implicit in the old implementation and improve the diagnostic messages. A good start would be to look at some of Tue code that I already converted to c++. If you have more questions please ask and I'll try to answer as soon as possible. I'll return next week from my vacation so I can answer questions after that also by irc.
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Can I work on it? If so, I will assign to me. Thanks in advance!
(In reply to comment #11) > Can I work on it? If so, I will assign to me. yes you can, but we have so many Java tests that assigning this bug to any person makes no sense, multiple people can work in parallel on different tests.
(In reply to comment #11) > Can I work on it? If so, I will assign to me. > > Thanks in advance! Have you worked on any of the tests? I'd like to hack at these too, but if you have already worked on something that's not on the main branch yet, it'd be nice to know.
(In reply to comment #9) > So I'll try to add a few more details but I'm currently on vacation. So > please excuse if it is not in as much detail as it should be. > > Currently our api test code is at qadevooo/tests/java/ and there in there in > the folders IFC and mod. > > The implementation is divided between these two folders to represent our two > parts of the api implementations. The sender IFC part is for the interface > definition that is represented in our api through the IDL files in offapi > and can be found at api.LibreOffice.org. the mod part is for the actual > implementation that implements several interfaces. > > We have a similar structure for the c++ tests. The test code for the > interfaces can be found in test/ and the code for the implementations for > calc in sc/qa/extras. > > Each file in sc/qa/extras represents one implementation file and is one > cppunit test that is registered by a make file in sc/ and in > sc/module_sc.mk. the new tests just make it explicit which interfaces are > tested while it is implicitly done in the old java tests by querying for all > interfaces the object provides. > > So we now need a two step process to convert old tests. First convert the > interface test code and implement it in test/ and secondly convert or better > write a clean new implementation for the api implementation. > > The c++ implementation should however try to make the tests better by using > the assertion macros that are provided by cppunit, make explicit what was > implicit in the old implementation and improve the diagnostic messages. A > good start would be to look at some of Tue code that I already converted to > c++. > > If you have more questions please ask and I'll try to answer as soon as > possible. I'll return next week from my vacation so I can answer questions > after that also by irc. This is what needs to be done, if I interpreted correctly: 1. Pick a folder from qaDevOOo/tests/java/ifc (Pick an interface) 2. Implement the interface picked into test/source (Organized into folders as in original implementation 3. Pick a folder from qaDevOOo/tests/java/mod (Test cases, organized in folders, let's call it mod_name here) 4. Implement the tests into the folder mod_name/qa/extras (mod_name folder at project root) Is this correct?
(In reply to comment #14) > > This is what needs to be done, if I interpreted correctly: > 1. Pick a folder from qaDevOOo/tests/java/ifc (Pick an interface) > 2. Implement the interface picked into test/source (Organized into folders > as in original implementation > 3. Pick a folder from qaDevOOo/tests/java/mod (Test cases, organized in > folders, let's call it mod_name here) > 4. Implement the tests into the folder mod_name/qa/extras (mod_name folder > at project root) > > Is this correct? Mainly. Just ask here on IRC for a specific context. Good cases that I currently have and that are hopefully not too difficult are: sc.ScTableSheetObj::com::sun::star::sheet::XCellRangeData sc.ScTabViewObj::com::sun::star::sheet::XRangeSelection sc.ScTableSheetsObj::com::sun::star::container::XNameReplace sc.ScTableSheetObj::com::sun::star::sheet::XPrintAreas sc.ScTableSheetObj::com::sun::star::sheet::XCellSeries sc.ScTableValidationObj::com::sun::star::sheet::TableValidation
(In reply to comment #15) Tried you on IRC. I think last thing I should ask before getting started is: are the unit tests run when I run make? Also, how do I know the unit tests are being run? Thanks.
Nevermind I just saw this: https://wiki.documentfoundation.org/Development/Unit_Tests
(In reply to comment #16) > (In reply to comment #15) > > Tried you on IRC. > > I think last thing I should ask before getting started is: are the unit > tests run when I run make? Also, how do I know the unit tests are being > run? Thanks. I'm always on IRC just not always on the computer. My nick is moggi. The tests are run with make sc.subsequentcheck after having added the test to sc/Module_sc.mk and creating the corresponding makefile for the test. The easiest part is just to copy and paste on of the other makefiles from an API test in the sc directory and change the line with the source file and the name. The same is true if you add a file to test/ for an API test. You still need to add the file to test/Library_subsequentcheck.mk and execute make test in the top level directory. If you have more problems please ask.
(In reply to comment #18) > (In reply to comment #16) > > (In reply to comment #15) > > > > Tried you on IRC. > > > > I think last thing I should ask before getting started is: are the unit > > tests run when I run make? Also, how do I know the unit tests are being > > run? Thanks. > > I'm always on IRC just not always on the computer. My nick is moggi. > > The tests are run with make sc.subsequentcheck after having added the test > to sc/Module_sc.mk and creating the corresponding makefile for the test. The > easiest part is just to copy and paste on of the other makefiles from an API > test in the sc directory and change the line with the source file and the > name. > > The same is true if you add a file to test/ for an API test. You still need > to add the file to test/Library_subsequentcheck.mk and execute make test in > the top level directory. > > If you have more problems please ask. Just a short tip to make it easier. While working ona new test it makes sense to remove the other tests from the subsequent test target in sc/Module_sc.mk.
*** Bug 48024 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.