For this week’s blog post I chose to focus on a topic that I had to research for an honors project, this being Jacoco. In case you are not familiar with it, Jacoco is a software tool that is used to test code coverage, which in short just involves checking how much of a system’s code is being tested. This may sound redundant if you, like myself, have only really been using tests on small scale projects, but as a program’s complexity increases so does the complexity of the tests required. Additionally you will have to write more and more tests, making it difficult to determine exactly what has been covered. Before anything else however, I am going to break down exactly how code coverage is checked.

Having not known about Jacoco at all, I found this article on Baeldung that was extremely useful in understanding how it worked. As I stated the essential idea is to check code coverage, which consists of line and branch coverage. Line coverage essentially means Jacoco will check how many lines of code are being executed during tests to determine which are actually being tested. Branch coverages is similar to this, but focuses on checking the logical splits in the program, such as conditionals like if statements. The total amount of branches present is then compared to the amount that were covered to give the results. There is one more aspect of a program Jacoco checks for, being cyclomatic complexity. This is essentially a measure of the logical complexity of the program, or how many branches the program has. Now that we know what Jacoco is we can discuss why you might want to use it.

This testing tool certainly has some major benefits for anyone working on a large system. If you are working on writing tests for a system, it may begin as something straightforward, but as the system grows it will become increasingly hard to track exactly what components are being tested. This is where Jacoco comes in, allowing you to see exactly what lines, or just classes, are being tested so you can ensure there is sufficient test coverage. Additionally it can show you the degree of logical complexity present in the system, which could then be adjusted accordingly. One point to keep in mind that is mention in this article is that you should not get tunnel vision when trying to increase code coverage. High code coverage does not necessarily mean the tests being run are adequately testing the system. It is more important to focus on writing a few functional tests for each component rather than just having a plethora of tests that do not really do much of value. This article discusses Jacoco in more detail than I can so if this interests you I would recommend checking it out!

Source:

https://www.baeldung.com/jacoco

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

            Having started to learn about stubs with relation to testing in class, I went to do some further research on the functionality and usefulness of this testing strategy. I found a great deal of articles comparing stubs with mocks and evaluating their differences. I haven’t heard of mock testing before, so this was interesting to look into. Turns out, it’s pretty similar to some work we did in class. I found this great article detailing the differences which also gives a simple, understandable example.

            The main difference in stubs vs mocks is that stubs are looking to see a certain behavior, while mocks are also setting an expectation and then verifying that expectation. This is demonstrated with the use of a couple examples. Stub methods are created in the example by not doing anything but printing out “_____ is working fine.” This is to check that the correct method is being called and in the proper context. On the other hand, a mock uses a third party library (Mockito) which creates a mock Mathematics object in a test setup. Then, still in setup, the expectation is set: when(maths.sub(2,1).thenReturn(1); This is just saying 2 – 1 = 1. And finally, this expectation is verified in the test with Assert.assertEquals(1, s.subNumbers(2,1)); If this explanation seems choppy, sorry, I tried to condense 44 lines of code down to just this. Anyways, the idea is that a mock object is made, expectations are set, and then they’re verified. So both stubs and mocks are useful kind of white-box-ish testing styles, but mocks seem to have a higher level of testability. This doesn’t mean they’re necessarily better or more useful, but they have their purpose too.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.