Category Archives: CS-443

Are you Mocking me?

The idea of mock objects used for testing makes me very excited. After struggling through an assignment on mocking in the very class I am writing this blog for, my excitement started to waver. Luckily I was able to get everything working after messing with gradle dependencies and the locations of files within the project and it was really a joy to see just how powerful mocking could be. I decided to look at mocking in greater detail for this blog post, because while the assignment we did in class did set up a good introduction, I feel like most of the assignment was spent setting up mockito, a really handy java mocking framework.

I found a really thorough article about mock testing written by Michael Minella (over a decade ago!) over at Dzone.com. While this article is ancient in terms of how quickly technology changes, I feel like all of the information given is still very relevant today, even if frameworks have changed a bit since then.

In the real world it is almost impossible to program without having to use dependencies. Mocking is one way to make sure that tests are only testing what needs to be tested, rather than testing the method in question and all of its dependencies. It allows you to create “Mock” objects that return desired outputs for their methods since tests should assume that any other methods that need to be called are working as intended. To reiterate what was said in the article, If a method has a dependency that returns an ArrayList, you most likely aren’t testing that ArrayList works as intended. You should assume that it works and test the method under that assumption. Mocks are proxy objects that only return what is necessary, eliminating any potential issues where the dependency could have an issue that would muddle the usefulness of the tests.

The article doesn’t go into detail about any specific frameworks but does talk about the how exactly the different types of frameworks work. According to the article, Mocking frameworks that use proxy objects, objects that are injected into the test file without modifying any other code, are far more popular than any other types of mocking frameworks.

This article is a must read for anyone looking to start using mocking in their unit tests. I feel like dealing with dependencies in my unit tests is something that I find myself struggling with and Mocking is most certainly a good solution to that.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Should Tests Drive Development?

After spending many hours reading about the benefits of TDD, Test Driven Development, I thought for sure that anyone attempting to program any other way was putting themselves at a huge disadvantage. I mean, who wouldn’t want to get work done faster, cleaner, and with more test coverage? While searching the internet for information about TDD I stumbled upon Robert C. Martin, one of the founders of Agile and writer of Clean Code‘s, blog. On his blog he wrote a post about a study done on TDD that actually proves that TDD brings no benefits into the workplace. As someone who read both Clean Code and Clean Coder I thought that Martin would disprove the study with an iron fist, yet that wasn’t the case.

Martin’s blog post was written in dialogue format which does make it pretty easy to follow along with his main points. Martin doesn’t outright deny the claims made by the writers of the study, rather he claims that their study wasn’t really testing two different ways of programming. The study had two groups work by programming in small chunks while one writes unit tests before, TDD, and the other writes their tests after, TLD, or Test Last Development. While it may seem like both of these ways of programming would yield massively different results there is an inherent problem with the way the study was carried out.

In order to program in small chunks, no matter when the tests are written, one has to think about the tests before writing the code. It is nearly impossible to know what a “small chunk” is for testing unless a test is already in your mind. This is the problem with the study. Both groups were essentially doing TDD except one group was writing the tests prior and one group was committing to the tests that would be written later prior.

The study shows that TDD doesn’t make you any faster or less prone to error than TLD, yet it seems like the two groups that were being studied were both doing a form of TDD, just one was using a less formal version. If there is anything that it seems one could take away from this test its this: writing code in small chunks, even if you aren’t writing the tests before, is the most efficient way to program. This study didn’t disprove TDD, rather it proved that one of the most important principles of TDD, writing code in small chunks, is extremely beneficial to all programmers.

One of my biggest issues when programming, and something that I find happens to me all to frequently, is I’ll have an idea for a way to solve a problem and I’ll chug away writing code until I think I have the whole problem solved. One “full send” later and a couple erroneous outputs and I’m lost as to what I should change in order to make my code passable. I feel like even if I am not using TDD completely when programming for things such as programming challenges, I should try and write in small chunks with the tests I will be writing in mind.

Overall a very fun read by “Uncle Bob” Martin. I am extremely glad I stumbled upon his blog because I enjoyed reading his books a great deal.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Imagine Getting Trash Talked By a Robot?

Alright everyone, I decided that for this week, I am going to move away from a QA article and talk about a general CS article. To be more specific, this article was about robots, and how even the words that they say can affect us humans. On first glance of the article, I read the title wrong and thought that humans were just bullying robots and seeing their reaction, but it is the opposite, robots are bullying humans.

The study conducted recently is a study about how human performance is affected by discouraging or encouraging words coming from a robot. They used a video game and the robot would comment on how the player was doing. It turns out that the robot saying mean things to the player about his performance caused the player to actually score lower than that of a player who was praised. As someone who dabbles in video games, I understand that people will talk about my bad skill, and I do believe that it makes players worse at what they are playing, but I didn’t think the words of a robot could have such an effect.

The test was conducted by Aaron M. Roth on about 40 participants. This test was important because most tests take a look at how humans and robots can cooperate, but this test looks at how they are when they are uncooperative. This isn’t tested as much so I fell that it is important to test this because as AI continues to develop and get better, we may see ourselves in a situation where a robot can become uncooperative. This study was done just to show that while human words definitely affect human performance, the words of a robot who is programmed to say such things can also be detrimental to us humans. We really are a weak race if I’m being honest.

I really enjoyed reading this article. The reason I chose to write this article over another QA article is that there are more ideas to write about in general CS where as QA articles are almost all the same. It is usually about the trends of 2019 or 2020. This was the first article I saw in the CS articles, and it was about robots bullying humans. This was really easy to read, and it was even easier to write about. My next blog is my last blog for the semester I believe, so hopefully there will be a great article for me to write about next week.

https://www.sciencedaily.com/releases/2019/11/191119075309.htm

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Mock testing

Mocking, or mock testing, is a really well known method in writing unit tests. With “mock” in English is to imitate or replica something, a mock object in programming can be seen as a place holder for another object that has the exact same behavior. With that being said, mocking would enable developers to use the mock object to simulate the real behavior of the real object in order to perform without having to worry about dependencies of the real object.

With a little help from mock frameworks that available for the majority of the languages, mock testings has become easier and more efficient to use. The first type of mock framework is Proxy based frameworks, and it would usually creates a mock object to be called by the test, and it can handle that call by delegate it to the original object, or do operations by itself. This type of frameworks is commonly used as because of its simplicity but still does have its own drawback. For instance, proxy based frameworks can neither be able to intercept static method calls, private method calls, final method call nor build a proxy for a final class. The second type of mock frameworks is classloader mapping as the program would tell the class loader to remap the reference to the class file it loads, so essentially it would load the mock class instead of the actual class.

Article reference can be found here.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Mock Testing

Recently in CS-443 I was introduced to testing using
mocking. Mock testing makes use of a mocking framework (we used Mockito in class)
to create mocks which the place of regular objects. A mock can call the methods
of its associated class or interface, but it will return a default value of 0
instead of actually running the behaviors specified in the class’ methods. It
is also possible to tell the mock to return specific values other than the
default to make sure that different methods return different results. It was
interesting to learn about implementing Mockito and working with mocks in my
projects, but there was one question that I kept asking myself: What is the
point? Why go through the trouble of setting up mocks when you could just
finish writing the code and test its actual behavior? I decided I would search
for an answer to these questions on my own, and in doing so I came across an
article by Michael Minella titled “The Concept of Mocking.”

The article can be found here:

https://dzone.com/articles/the-concept-mocking

Unlike the example in class, this article teaches mocking
and its purpose clearly and simply. This purpose, as the article explains, is
to test functions without executing other functions that they depend on. The
article demonstrates this with a simple example which includes a doLookup
method that calls a lookupByKey method. By using mocks, it is possible to test
doLookup without needing to make sure lookupByKey is also working correctly. This
extremely simple example has helped make the point of mocking much clearer to
me. It still seems better to me to write tests based on the actual code of a
project, but I can see mocking being useful in situations where the code a project
depends on is not all accessible. I think the example in class may have been
too complex an introduction to mocking, and the difficulties I had getting the
example code to work made it difficult for me to understand the basic concepts behind
mocking. The simplicity of this article enabled me to see the purpose of
mocking, which I think will make it easier for me to apply what I learned from
the class activity.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Another Example for the Decision Table Test Design Technique

we can use the following function to create a decision table. int discountcommission(double price, int items) returns the percent discount , when given the price of the items. Items Discount Commission items < 100%15 ≤ items ≤ 506%51 < items 12% for all sales that’s over $1000.00 additional 1% discount will be given. Let’s try … Continue reading Another Example for the Decision Table Test Design Technique →

From the blog CS@Worcester – Shams&#039;s Bits and Bytes by Shsms Al Farees and used with permission of the author. All other rights reserved by the author.

Time to cover up

For this post, I looked for some info on code coverage. Garrett Levy’s article “The Importance of Code Coverage,” covers the types of code coverage and why they are important. It is a short read and it helped clear up some uncertainties I had.

The article starts off by explaining the reasons for code
coverage. Put simply, code coverage calculates the behavior of test code and sees
which lines and branches are tested. This is useful because testers can see
where their test code is incomplete and missing test cases.

Levy then describes four types of coverage. First, statement
coverage is the amount of code statements that were used during testing. Next,
branch coverage is the number of branches caused by conditional statements that
have been tested. Function coverage test which functions have been used during
testing. And finally, line coverage tests which code lines have been used
during testing. By using all four, a tester can easily see what cases are missing
in the tests.

I found Garrett Levy’s article, “The Importance of Code
Coverage,” to be a quick read that helped me get a clearer idea of code
coverage.

Article Referenced:
https://blog.cloudboost.io/the-importance-of-code-coverage-9b4d513f39b4

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Mockito, not the lovely beverage Mojito

Does your unit test have a stunt double? You know someone to jump in there and take the hit during testing instead of using real dependencies? Well, it could if you used Mockito. I found a great tutorial on setting up Mockito for various environments and situations here: https://www.vogella.com/tutorials/Mockito/article.html But what is Mockito? Don’t confuse it with that lovely mint based rum concoction. It’s a JAVA based mocking framework. It’s used to mock interfaces so that dummy functionality can be used in unit testing. But what is mocking? In OOP mock objects are simulated objects that mimic the behavior of real objects (stunt doubles!). In Test Driven Development mock objects meet interface requirements of real objects allowing developers to write and unit-test functionality. This allows the developers to focus on the behavior of the system while testing without worrying about dependencies. This Martin Fowler article does a great job explaining Mocks: https://martinfowler.com/articles/mocksArentStubs.html So grab a Mojito and enjoy some reading! #CS@Worcester #CS-443

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Getting Checkstyle-ish

After today’s CS443 class, I decided to look further into Checkstyle. “How Open-Sourced Projects use Checkstyle,” by Sider Team is a thorough article about Checkstyle. I focused on the sections containing the Checkstyle overview, the default check item categories, and the default coding styles included with Checkstyle. After doing this, I would recommend to others to read through the fourteen categories of default check items. Sider Team has provided descriptions with simple, clear examples for each category.

In the section with the default coding styles, the two
styles we used in class are mentioned. Sun Java coding style was a popular
style that is no longer maintained and possesses outdated rules. Google Java
coding style, on the other hand, is a newer and still actively maintained style
that has become popular since its debut in 2013.

After reading Sider Team’s article “How Open-Sourced Projects use Checkstyle,” I feel I understand Checkstyle, and coding styles in general, better.

Article Referenced:
https://blog.sideci.com/an-overview-of-checkstyle-and-how-it-is-used-in-open-sourced-projects-8dc288f65fdb

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

10 Software Testing Trends

Hello again everyone and welcome to my fourth entry for the semester on this blog. today we are going to talk about some software testing trends. As the title of this post suggests, we will be talking about ten of them today. The article was written by Ulf Eriksson (Really cool name) and i started this article by skimming and it seems to be very short and concise, which means it’ll be easier for me to write about. I will only be writing about the five i found the most interesting.

So obviously, this article is going to be about trends that everyone should be seeing in 2019. Ulf leads off with mentioning the “evolution of new testing approaches” (Eriksson) due to new developments with Agile and DevOps. He then begins his list with discussing Agile. He says that Agile is being used in more and more comapanies. He then talks about what Agile is and how it works, but if you’re reading this you probably know what agile is so I won’t bore you with that. The next part caught my eye because it has to do with machine testing. I don’t know much about machine testing, but it still has my interest. Ulf describes how it is used as follows: Test suite optimization (redundancy), predictive analytics(key parameters), log analytics(automatic executing), traceability (test coverage), and defect analytics(identifying high risk areas). The next trend is the adoption of DevOps. This part was very short and it talks about continuous integration and continuous delivery. Another trend was shortening the delivery cycle. This section talks about how new technologies are being used in order to speed up the deliveries. This is interesting because this will always be a trend. New technologies are coming out everyday, so it is impossible for this trend to die down. Ulf also discusses big data testing as a trend, and I chose to write about this because it isn’t my concentration so it is interesting to read about this considering I am not studying it. Basically this kind of testing makes sure the large amounts of data are being verified correctly. In other words, this tests the quantity and quality of data.

I would have loved to write about every trend on this list, but this blog would be way too long and I would lose all my reader(s) about halfway through. However, Ulf Eriksson did a great job with this article. He didn’t go into much detail about every trend because some of them should have already been known. However, the lesser know trends were explained very well. This article was a very interesting read because I’m in quality assurance testing now, and it is nice seeing topics I learned in class in articles. I would recommend this to any testers out there.

https://dzone.com/articles/10-software-testing-trends-to-watch-out-for-in-201

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.