what is Path Testing? It is a way or a method of testing to ensure that all the lines in the program is executed once at least. There is Program Graphs, Decision-to-Decision (DD) Paths, Test Coverage with Program Graphs and DD-Path Graphs
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.
Last week in CS-443, we did a class activity on static testing tools. These tools are able to detect issues in a program without executing the code. Previous activities had focused on dynamic testing, which does involve code execution, so static testing was definitely new to me. However, I had a hard time learning about the tools due to problems I had with the activity. One of its early parts involved building and running a batch file for the project we were working with. This batch file refused to run properly on my computer, so I was unable to progress with the activity and thus did not get to work with the static testing tools for myself. I observed what my group’s technician did with the tools, and it was interesting to see them in action, but I had a hard time understanding what the tools were doing since I was not working with them myself. Today, I decided to address this problem by revisiting the activity on my own and doing extra research into static testing.
Unfortunately, I was unable to get the batch file to run on my computer. No matter what I tried, it always failed to find or load the main class of the project. After about an hour of messing with file directories, I decided it was not worth spending more time trying to get the batch file to work. I was able to run the project using the gradle run command, and I decided to move on so I could actually try working with a static testing tool. The tool I worked with was Checkstyle, which looks over the code and makes sure it complies with the style guidelines specified in an xml file. I found it interesting that the tool is fully customizable, as the guidelines it checks for can be changed by altering the xml file that the tool uses. The tool is also extremely simple to add to a project, as it only requires a few extra lines in the build.gradle file: one to add the plugin, one to state which version to use, and one to declare which xml file contains the style guidelines.
Although I was able to figure out Checkstyle, I still was not sure I understood the fundamentals of static testing. I decided to do more research instead of continuing with the activity, and I came across an article from Guru99.com about the basics of static testing and testing review. I think the article does a great job introducing the concept of static testing and explaining why and how it is used. It is from reading this article that I learned the difference between static and dynamic testing. It also explained to me why static testing is used and introduced me to different types of static testing, such as manual reviews. I won’t go into every detail about the article here, but it definitely helped me make more sense of static testing and I certainly recommend it to anyone who is also confused by it.
You can find the article here:
https://www.guru99.com/testing-review.html
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.
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.
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.
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.
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.
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”
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.
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.
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.
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.