Hi, in this article I will share the details of what I did in the first phase of the summer with LibreOffice. If you don’t know what I’m talking about, you can refer to the following URLs to read more about “it”:
The first phase was unit testing phase, in which I had to write unit tests for gallery functions before I refactor them.
I started working on it in the community bonding period itself to get a head start on my project. May 2020 and the first week of June was spent completing this phase.
CppUnit testing framework was used to carry out the unit testing
I will now share the details about each unit test that I wrote.
- Test name: TestCreateTheme — create a theme and checks if it’s valid
Create a temporary directory, assert if it’s valid. Create an instance of Gallery class inside the directory. Assert if gallery was created successfully. Run CreateTheme(“foobar”) and assert if the theme was created, using HasTheme(“foobar”).
- Test name: TestDeleteTheme — delete a theme and verify it’s deleted.
Do everything in (1). Delete the theme using RemoveTheme(“foobar”) and verify that the theme doesn’t exist anymore. HasTheme(“foobar”) should return false. Also check that the files don’t exist — you have the URL of directory, say themeFooBarDirURL.
fileExists(themeFooBarDirURL + “/foobar.thm”)) should return false. Same with .sdg, .sdv and .str files.
- Test name: TestSetThemeName — rename the theme and assert that the name is changed
Do everything in (1). Set a new name of the theme, using RenameTheme(“foobar”,“barbaz”). Assert that a theme with the old name doesn’t exist anymore — HasTheme(“foobar”) should return false. Assert that a theme with new name exists now — HasTheme(“barbaz”) should return true. Final assertion: The names of the files are NOT renamed. They are rigid and will not be renamed if you rename the theme.
- Test name: TestThemeURLCase — use mixed case to name a theme and assert that it’s done successfully
This one is a bit tricky. Do everything in (1) except the name of theme should be in mixed case — say CreateTheme(“FooBar”). Now, the interesting part is that the files are stored in lowercase in UNIX based operating systems. So for example, in Linux, the file is saved as “foobar.thm” and in Windows, as “FooBar.thm”. So, I added an OS specific assert statement which will convert the theme name to lowercase in Unix based system and then verify if the files are there or not.
- Test name: TestThemeCount — add and remove multiple themes and verify the theme count
Name says it call, really simple one. I’ve done it with loop, adding and removing the themes and running GetThemeCount() function each time.
- Test name: TestGalleryThemeEntry — get GalleryThemeEntry instance
It uses GetThemeInfo(“foobar”) to get the GalleryThemeEntry instance. If you recall from the UML diagram from my last post (here’s the link), GalleryThemeEntry is a member of Gallery as well as GalleryTheme. Then use the instance to GetThemeName(), GetThmURL(), GetSdvURL(), GetSdgURL(), GetStrURL(). Finally, assert that they’re correct.
- Test name: TestInsertGalleryObject — insert a gallery object into a theme
I’ve created a vector of image names and added to a theme “foobar” using InsertURL() method. And then check if the images(objects) have been inserted successfully: IsValid(). I’ve used jpg, png, etc. formats. Check the consistency of the object count using GetObjectCount().
- Test name: TestRemoveGalleryObject — remove a gallery object from theme
Do everything in (7) and remove the objects from the theme using RemoveObject() method. Check the consistency of the object count using GetObjectCount().
- Test name: TestChangePositionGalleryObject — change the positions of objects in a theme
Do everything in (7). Test ChangeObjectPos() and change the positions of the objects in the created theme. Assert.
- Test name: TestGetThemeNameFromGalleryTheme — get GalleryTheme instance and test it’s function
Test GetName() function in GalleryTheme and assert that the name returned is correct.
- I was able to write 10 unit tests for gallery module contributing ~500 lines of code in the first phase of the project.
- Previously, there were no tests available for the same. Now each time Jenkins will run the build, it will test if there is any inconsistency or any failed tests, which reduced risk of failure and improved quality of code.
- More unit tests means less bugs, that means reduced costs of bug fixing.
- Now that we have unit tests in place, we can proceed for refactoring confidently.
It was a good start for the project, and I got familiar with the code which helped me grab a grip on various parts of it. It was done before the deadline so I could relax for a bit before starting refactoring 😛. I should have written article at that time only — hindsight. 😅
After writing the tests, I could refactor the code without any problems. Check out my next post for gallery code refactoring!