Overview

The goal of the home assignment is to practice the verification techniques (e.g. code review, testing, CI) on a real project.

• The home assignment is mandatory. However, it will not be graded, the outcome is just accepted/note accepted.
• The home assignment shall be solved in teams of 3 or 4.
  • Students form teams.
  • All members of the team should contribute to the home assignment.
  • All members receive the same outcome, unless the team reports that one of the members has not contributed to the joint work.

The assignment consists of solving predefined tasks on a public, open source GitHub project. The team will receive a pubic repository in the BME-MIT-IET GitHub organization. The team shall upload the actual state of the master branch of the selected project. The team will have admin access on its own repository, but it is forbidden to rename the repository or change its access permissions. [Note: in practice, you should create a fork if you would like to contribute to an open source project. However, we are creating now a separate repository in order to be it independent of the original, and to prevent sending pull request accidentally to the original repository.]

Projects to select

• From a predefined list (link).
• Own recommendation (e.g. your own project or a project you use). In this case first send an inquiry in an email to the instructor (Zoltan Micskei).

Tasks to complete

As a first step the team shall get familiar with the selected project:

• Read the documentation, check out the structure of the code base, try to run the project, do some basic testing (if the project has a UI) or write some simple code to access the project (if the selected project is a library).
• In a file IVT-assignment.md in the team’s repository write a short summary about the project, its goals and select some of the features to work with later.

The subsequent tasks are assigned to two main groups (static techniques and testing). For each of the tasks we listed some example tool to use, but the team can choose any relevant tool for solving the tasks.

CI and static techniques

• Adding a build framework if not used yet (Maven, Gradle...)
• Adding a CI framework to the project if not used yet (Travis, AppVeyor...)
• Running a static analysis tool and reviewing the reported problems (SonarQube, FindBugs, VS Code Analyzer, Codacy, Coverity Scan...). As static analysis tools could find numerous problems, it is enough to review only a subset of them. If the team agrees with the reported problem, it can fix some of them. Try to review different types of problem and concentrate on more complex ones (e.g. not just formatting errors).
• Performing manual code review on some part of the application (GitHub, Gerrit...)
• Supporting deployment (Docker, Vagrant...)

Testing

• Creating or extending unit tests (xUnit...)
• Measuring code coverage for tests and extending test suite based on the results (JaCoCo, OpenCover, Coveralls, Codecov.io...)
• Creating UI tests (Selenium, Sikuli, Appium...)
• Creating integration/systems tests (Wiremock, Pact...)
• Adding BDD tests (Cucumber, Specflow...)
• Designing, executing and documenting manual tests

The team shall choose at least 2-2 tasks from each group. The team can decide which tasks to choose (based on the characteristics of the selected project or the preference of the team members). More than one team member should work on a given task. After completing a task, a team member who has not worked on the given task shall review the work of the others.

IMPORTANT Each team member shall work at least 15 hours on the home assignment. The team shall plan how to use the most efficiently this time budget, and the team shall concentrate on those tasks that are useful for the project and could reveal the most from the current state of the project or increase its quality.

Documenting the work

• The team shall open a separate issue for each of the selected tasks to report on the progress of the task. The team members shall discuss in the issue their plans and the responsibilities of each team member, and later they shall link the relevant commits or pull requests to this issue.
• The team shall document each task in a separate file in the doc folder of the team’s repository. Each file shall contain a short overview of the work performed (1-2 paragraph), and shall summarize the main results and the lessons learnt. Use the Markdown or AsciiDoc format for the files.

Grading

• The team shall present the results of the home assignment at the last week of the semester.
• Grading is based in quality and not quantity. The team shall not put emphasis on e.g. how whether 15 or 20 tests were written, instead the team shall focus on what they learnt from the assignment about the quality of the project or the applied verification techniques. Pay attention to perform useful work, e.g. creating numerous unit tests for getters and setters is not really helpful.
• The team shall pay attention to perform professional, high quality work (clean code, clear commit messages, organized repository, helpful documentation…). This would be also assessed by the instructors at the presentation of the solutions.

Deadlines

• 17^th May 2020: tasks finished and documented in the repository
• 18^th May 2020: presentation of the results
• 26^th May 2020: re-submission of improved solutions if necessary