Dataverse: Refactoring Unit Tests with Parameterized Class

[alexscheitlin]

Hi guys,

we are three developers and Computer Science master students at the University of Zurich in Switzerland. We are improving our testing skills with JUnit as part of a software testing lab in the current semester. If you have any pointers as for where we could/should start looking at the codebase with regards to testing, this would be very welcome and helpful.

We will use this issue to refer to in our commits, branches, and pull requests if that is ok with you.

Thanks a lot and best regards,
Alex (alexscheitlin)
Nik (nikzaugg)
Roland (rschlaefli)

[pdurbin]

@alexscheitlin @nikzaugg @rschlaefli hi! Thanks for your interest in contributing! I can see you're writing code already! It's not reflected at https://dataverse.org/community-calls yet but my first thought is that perhaps some or all of you could join in our next community call on Tuesday. We have these calls every other week. You can also find some of us at http://chat.dataverse.org during the work week. Thanks!

[pdurbin]

A few more thoughts for you:

• We track code coverage of unit tests at https://coveralls.io/github/IQSS/dataverse which is linked from the README. I'll put a screenshot below.
• We don't track code coverage of integration tests but some groundwork was laid in pull request #5016
• We don't have a great process for running integration tests before merging pull requests.
• You can find a brain dump of ideas for improving testing at http://guides.dataverse.org/en/4.11/developers/testing.html#future-work

Please let us know how we can help you get oriented with Dataverse. 😄

[rschlaefli]

Hi @pdurbin!

Thanks for the warm welcome and pointing us to the right resources. As you already saw, we have started working on refactoring some tests. We get a biweekly assignment of what techniques to apply in our chosen codebase (yours). More specifically, our current task consists of refactoring several tests to use parametrized testing (data-driven testing), as well as creating several new unit tests for inputs not yet covered. We do not yet have information about the remainder of the assignments.

We are expected to submit pull requests as part of our assignments. Whether you finally merge them will surely be up for discussion and might need more work, as e.g. our current task encourages us to refactor 3 unit tests in 3 different classes, instead of cleanly refactoring an entire class.

As for the community call: we will try to join the call today (if we manage to do it via web). We might need to leave after ~30min, as it is already later in the day here in Switzerland and we have plans for the evening :)

[pdurbin]

@alexscheitlin @nikzaugg @rschlaefli thanks for calling in yesterday! I just posted the notes to https://groups.google.com/d/msg/dataverse-community/y8VilZxBYSw/NLSSyh_CBwAJ

It's great that you're expected to make pull requests. One expectation I'd like to set is that we like working in small chunks. At http://guides.dataverse.org/en/4.11/developers/version-control.html#how-to-make-a-pull-request we mention that smaller pull requests are easier to code review. I was just looking at https://github.com/IQSS/dataverse/compare/develop...alexscheitlin:5619-improve-testing and I'd say you could go ahead and create a pull request now or soon, whenever you're ready. Then you'll get a feel for how issues move across our board at https://waffle.io/IQSS/dataverse

Once the pull request is made, you would create follow up issues that reference this one. You could call them "improve testing, round 2" or "round 3" or whatever.

Please let us know if you have any questions! Thanks!

[alexscheitlin]

@pdurbin thanks for your message. Like mentioned yesterday in the call, we bi-weekly get new assignments. For this assignment for example, there is one task where each of us is supposed to refactor three unit tests using the Parameterized or Theory class and another task to write three new unit tests. So the changes you see here develop...alexscheitlin:5619-improve-testing are for the first task and will be used for one pull request.

How would you like us to create the pull requests? Should we

1. create a new issue referencing this one, describing the task and what we will focus on
2. create branches with the issue number (one branch in each fork)
3. create pull requests for this issue (three pull requests for one issue, one from each fork)

We know this is not the preferable way of creating ONE issue, working on ONE branch and then creating ONE pull request for this issue. If you'd prefer a separate issue for each pull request (rather than one issue per task) we can also do that.

Just let us know how it works best for you! Thanks!

[pdurbin]

When you are finished with the Parameterized and Theory work, please make a pull request for this issue. As part of the pull request, please consider editing doc/sphinx-guides/source/developers/testing.rst to talk a little about what you're up to. We'll associate that pull request with this issue in Waffle and move it to code review. Perhaps you could edit the title of this issue to explain a little more what the task is about.

Then, please make a second issue for the next task. I would suggest creating a new branch from the branch you made in your first pull request to build upon your work there. One that task is completed to your satisfaction, you can make a second pull request.

Etc, etc for subsequent issues and pull requests. Please let me know if anything is unclear. Thanks!

[alexscheitlin]

Okey, we'll do that. Thanks!

[pdurbin]

@alexscheitlin @nikzaugg @rschlaefli pull request #5635 (your first one) was merged! Thank you! One thing we're curious about is... How did you find us? How did you learn about Dataverse? Why did you pick our project? Thanks!

[nikzaugg]

Hi @pdurbin

We started looking on GitHub for an interesting open source project that uses Java, maven, JUnit and some CI-pipeline. Additionally, it was important to us that the project community was active and open to new contributions. As mentioned, we are doing this as part of a software testing laboratory, and therefore a lower test coverage means more room for us to test and get hands-on experience.

[djbrooke]

Thanks for the important contributions @nikzaugg @alexscheitlin @rschlaefli!