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.

FINAL PROJECT SECOND BLOG

This week we started to code our project, after we finished the UML design now we have the map to our code. Also we are using GitLab to share our work, each time any one of us is done with a part of the code we just push it to GitLab so every one can … Continue reading FINAL PROJECT SECOND BLOG →

From the blog CS@Worcester – Shams's Bits and Bytes by Shsms Al Farees 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.

FPL&S 4: User Login, Email Verification, and a Hard Lesson in “this.”

Before creating a database, I needed a way to associate files with a user. This requires user authentication, which is thankfully provided by Google Firebase. In my experience, 3rd Normal Form (3NF) is the best compromise in database normalization, so I strive to achieve this when creating one. Therefore, instead of blindly implementing file storage for a single user, I put some thought in ahead of time of how I would store the data. Currently there are not many data to store, but 3NF is helpful in allowing for additions to a database in the future.

Google’s authentication provides a familiar, smooth interface for users to login or create a new account. In properly-designed, object-oriented software, it is a quick and secure way to implement authentication to quickly launch a product and still easily replace it with your own authentication implementation in the future. The API took a little getting used to (and again, their documentation is not easily converted to Typescript), but it only took a few hiccups to get everything working reliably.

The biggest of the hiccups was “this.”, (pronounced “this-dot”) when referring to member variables. I’ve heard legends of the horror of “this.” in JavaScript. I’ve seen Twitter posts lamenting the language for its strange behavior. But I never expected this.

In typical Java fashion, I was using callbacks for the authentication service. The module would need to update member variables, which are bound to elements through the *ng-if directive. Coming from Java, I naturally assumed calling “this.variable” within the callback would change the value, and the console was printing the correct value, but only within the callback function. As soon as it finished, “this.variable” was the old value. As it turned out, I was referring to two different “this’s”.

The problem is that “this” refers to the context in which a variable is called, not the class in which it is defined. This Stack Overflow post has some good answers describing why and the proper way to use it. My solution was to use arrow functions to pass the correct context to the callback function when I subscribed to it, like so:

ngOnInit() {
    this.angularFireAuth.authState.subscribe((user) => {
        this.firebaseAuthChangeListener(user, this);
    });
}

Subscribing to the authState gives us a user object, which needs to be passed to the custom callback function. ngOnInit() is called to initialize the Component, so the context is the Component itself. Therefore, we can refer to it using “this”, which we do to refer to other services and methods. Modifying the callback function to also take the context means we can modify the member variables of the Component using this argument.

I tried a few other solutions, but this was the simplest and the only one that reliably worked. If there are better TypeScript solutions, I’d love to hear them. For now, I can reliably register users and use their unique IDs to associate them with their file uploads in the database.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

Final Project Progress

For my final project in CS 343, I have chosen to create a
Pokédex SPA that uses a public database, PokeAPI, with RESTful API. So, my
focus has been on page layout and how to search for data with limited methods
since the backend is all set.

I went through several different ways of trying to set up
the page layout, but eventually I settled on CSS grids. I found these grids to
be intuitive and easy to manipulate. It was not long until I was able to
successfully create a basic layout to work with. I used the grid-template-areas
CSS property to set a dynamically resizable layout.

CSS:       grid-template-areas:
     “header header”
                                                                “menu content”
                                                                “footer
footer”

Current page progress

I used the CSS fractional units to determine the width of
the columns (1:4) and static sizes for the height of the header and footer with
the content in-between filling the page. Now that I have a basic layout to work
with, I can focus on added functionality.

A function I have currently implemented is a search for Pokémon
by id number or name. For now, the page simply displays the name, image, and id,
but the API provides much more data that I haven’t included. The evolution tree
function is still a WIP. Connecting the evolution chains to the specified Pokémon
was a small issue. The API does not provide a way for an evolution chain to be
searched for by Pokémon. I eventually settled on creating a map, at page load, by
looping through all available chains and pairing them with their respected Pokémon.
The plan is to use the chain to render a pop-up that displays the entire evolutionary
tree. I also have a moves search that works similarly to the Pokémon search.

I am now trying to think of ways of using the pokeAPI in interesting ways. I will probably add some more search options to the menu as well as adding more options for linking relevant data. Even though my project is still fairly new, I have learned a great deal about HTML and CSS so far.

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.

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.

Using UML for a project

I have have been working on a big term project lately for my all classes. I when me and my group were planning what to do I decided to try use a UML to do the planning like I had learned about in my class a few months ago. It was big help in figuring about how to structure the program and figure out how make it work. It also help a lot with being able to communicate with group members so we could all work on it at same and it would still be compatible.

From the blog CS@Worcester – Tim’s Blog by therbsty 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.

Projects, projects, projects…

Working on the Final Project for the Software Architecture class has been fun so far. During this initial week we had to figure out what are we going to do. I have paired with one of my classmates named Zac to work together. All we knew that the project was supposed to be done with the TypeScript and Angular framework. Well then what to do? We had no idea, at least at first, until we got the Databases class where again I have paired with Zac and we were supposed to do a project with databases and some SQL. That is where it hit us: “how about we combine both projects?”, what we meant is using Angular we can create a website that will connect and interact with a database through a REST API we learned about before. Genius I say, only problem was to figure out if that will be allowed, killing two birds with one stone, and guess what, it was ok.

So, with that in mind we went to work. First step was to figure
out what database do we want to use, since that will decide on what shape rest
of the project will take. That is where Zac came in, he is a very talented
musician and he quickly found a free database online that relates to music, it
had quite a few entries, but not too many so it will be fine working with it.

Great, a third the setup is done, step two create a
Wireframe and write a proposal for both classes. Huh, a what? Well apparently,
wireframe is a visual/conceptual design for a web app. Here is some
explanation. That helped us so we went to work. I tell you what trying to
design how a website will look is not that easy, me and Zac had to discuss few
things before we settled on something. Version one is not very impressive and
will most likely change but good enough for now. With it we had the conceptual
work done.

Now all that is left is to make it a reality. Well easier
said than done but that is why we are in school, to learn those kinds of things.
We have started with the basics; can we use Java to talk to a Database? Luckily
in that regard professor from Databases class helped. (here is the
article about it) Ok so we can talk, let’s see if me and my teammate can do
some simple queries with the REST API. YES, WE CAN! Ok we are in business. More
fun will come next, use what we receive from the database and make it work with
Angular, but I will talk about that later…….

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Testing with MOCKING

Having learned about mocking it was finally time to put it to test. We were given some code and exercises to work with and learn by practice, I love that by the way, POGIL is awesome. We were given a Mocking Framework called Mockito to use and it seems like it is a very useful tool for testing.
I am still a little bit confused about Mockito and its use (practical side) but that is fine, there is plenty of knowledge base right on their own website here. Yes their logo is a Mojito…. I have read few things and it helped me to better understand the framework, the website also has links to FAQ and blogs by the creators. I believe anybody will be able to work with Mockito after doing some reading and maybe some practice.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.