PV260 Software Quality
Assignment 3 - Static Code Analysis, Unit testing, Development problems
Spring 2018
1 General Information
1.1 Dates
• Assignment start: 7. 5. 2018 (java1), 14. 5. 2018 (java2)
• Assignment deadline: 24. 5. 2018 (java1), 31. 5. 2018 (java2)
1.2 Submission
Task 1 Submit a .jar ﬁle as speciﬁed by the Task
Task 2 Submit a .jar/.zip ﬁle containing only source ﬁles or a link to a Github repository to the
Homework vault.
Task 3 Answers can be submitted in .txt, .doc, .odt, .docx or .pdf formats, but .pdf is preferred.
The tasks should be solved in the groups of two. Only one solution per group should be
submitted.
1.3 Evaluation
The maximum points for this is assignment is 15. Each task is worth 5 points. Additional points
can be awarded for submitting very nice solutions.
2 Mandatory Tasks
2.1 Task 1
• Using Checkstyle, write a Check module which will look for the Brain Method identity disharmony
as described in https://is.muni.cz/auth/el/1433/jaro2018/PV260/um/seminars/
java_groups/63275978/identity-disharmonies.pdf, page 92.
• Your module should be conﬁgurable through the standard Checkstyle xml analysis conﬁguration
ﬁle on all parameters mentioned in the Disharmony description:
– How many LOC the method must have to be considered excessively large
– How high cyclomatic complexity is allowed before the method can be considered a Brain
Method
– How deep nesting of control logic is allowed in the method before it can be considered
a Brain Method
– How many variables must be used inside the method before it can be considered a Brain
Method
• It is not required that you write tests for the module. However, to prove your solution works,
write a few example dummy methods on which your module can be run and gives correct
results.
• In the .jar ﬁle with your module also include the test ﬁle mentioned above and anything else
necessary for the module to be usable in Checkstyle.
1
2.2 Task 2
• Using the project ProductFilter: https://github.com/stanozm/PV260-ProductFilter.git write
unit tests for classes AtLeastNOfFilter and Controller which will test the following behavior:
• AtLeastNOfFilter:
– The constructor throws the exceptions as documented
– The ﬁlter passes if at least exactly n child ﬁlters pass
– The ﬁlter fails if at most n-1 child ﬁlters pass
– Try to only use the AtLeastNOfFilter class itself in the tests, do not depend on other
project classes
• Controller:
– The controller sends exactly the products selected by the provided ﬁlter to Output
– The controller logs the message in documented format on success
– If exception occurs when obtaining the Product data, Controller logs this exception
– If exception occurs when obtaining the Product data, nothing is passed to the Output
• Use Mockito at least once to create one of the Test Doubles needed.
• Create at least one Test Double manually (without the use of any mocking framework).
• Do not modify the sources in any way. Only add your unit tests to the test folder.
2.3 Task 3
For each of the following problems, do the following:
1. Find at least 3 of the possible/probable root causes of the problem
2. Find at least 3 possible reasonable solutions or the next action steps.
3. For the possible solution you like the most, write at least 2 non-trivial problems you may
encounter when implementing the solution.
Problems:
1. Customers often ﬁnd out really serious security bugs aﬀecting them, representing a threat to
them. Some of the customers share that bug with public / actively write about it to other
of your customers.
2. Your acceptance tests run 20 hours in CI. You cannot use CI for veriﬁcation of emergency
ﬁxes as it takes too long to get relevant results from it. That means sometimes emergency
ﬁxes are released uncomfortably late (waiting for tests to be executed), sometimes not properly
tested.
3. Other teams (the same teams over and over again) often break your tests in CI in master
and future-release branches. Most of those test failures catch real problems. You spend a
lot of time on failing test investigation and teams must often solve problems not long before
the release.
4. Company is not using, but want to use Continuous Delivery and there have already been
done analysis that the nature of their business allows Continuous Delivery in theory.
5. Company ﬁxed a bug in production, then re-injected it to production again, then ﬁxed it,
then re-injected it again. This happened several times for several diﬀerent bugs.
6. QAs do not know what exactly to verify with bug ﬁxes, they sometimes spend unnecessary
too much time on the veriﬁcation (they are retesting what automated tests already tested
and/or ﬁguring out for a long time what to test) and sometimes also do not catch some bug
which they could and should caught and the bug gets it to production.
7. Your team is ﬁxing bugs all the time and spends no/very little time for new features. Product
Management wants to develop new features to improve the business.
2
8. One developer in your team likes to give very detailed code reviews to others with lots of
comments and often insists on the comments being ﬁxed even when other developers whose
code is being reviewed, do not think those comments need to be ﬁxed.
9. You are working in a big company with hundreds of developers. Mainline branch is very
often broken, often needs to be locked to ﬁx the failing tests and that blocks integration of
new changes.
10. You are at the top development leadership in a big company which develops new and new
versions of the cloud-based product and you make new release of the product every week.
Your product is business critical for your customers and there are often injections with the
new releases, which breaks basic functionality for some of your customers and they are often
angry. The code coverage is around 40 percent.
11. You are a QA lead and your employees often tell you it’s hard to cooperate with Technical
Support to them as the Technical Support has often poor product knowledge. Also the
percentage of issues ending up closed as invalid suggests your QAs might be true.
12. You are quite a new developer in a team assigned to do a Code Review for your colleague.
It’s your ﬁrst code review and he just added you to the code review and did not talk to you
about that. You are not sure how to do the code review.
3