Category Archives: CS443

Regression Testing

Article link: https://dzone.com/articles/what-is-regression-testing-and-why-is-it-important

Today I learned about regression testing from an excellent article on DZone and why it is an essential part of software testing. As the article explains, regression testing involves testing the whole software product to ensure that any changes to the code doesn’t break what was already working in the product or other parts of the software. The article then goes through a great example of how fixing a bug in one part of an example piece of software can unintentionally result in another (previously working) part of the system to stop working properly. The article demonstrates really well that this breakage can occur despite unit tests showing that the bug was fixed properly. This to me is an especially important point as it shows the value in using multiple methods of testing to ensure software is performing correctly. One criticism I do have of this article is that I wish they gave an example of how to implement regression (the article does include a link to a tool that performs regression testing) testing in an actual program (or in context of their previous example).

Although after reading this article, the concept of regression testing seems simple, I find it very important as both a software user and software developer. In my personal experience as a user I have seen everything from operating systems to video games release updates that caused features that worked fine previously to become buggy or stop working entirely. From the user perspective I know how frustrating this can be, so I am glad that I learned how to prevent this problem as a software developer. Regression testing is definitely something I now want to implement into my personal software projects. Now I need to look into the tools that can help do this.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Technical Review

The school semester is almost over and slowly everything is coming to a completion. This will be my last post for the Testing Class, Over the course of it I have learned quite a lot of valuable skills in the Computer Science field.

The last covered topic of the class was the Technical Review, maybe not as advanced as previous exercises this one let us practice probably one of the most important and widely used techniques, the Technical Review, or simply code review. Some info about that can be found here. This is a form of static white-box testing technique which is conducted to spot the defects early in the life cycle that cannot be detected by black box testing techniques. It should not be lead by a person who wrote the code, or at least one member of the review has to be a somebody not associated with the code.

This is a very good and very easy form of troubleshooting and detecting bugs early in the production, and it should be used as soon as possible after the implementation of the code .

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.

First STUBS now others…

Last time I have learned abut Stubs in programming, this time I came to find out that there is more to it then I thought. For the Testing class we had to read this article by Martin Fowler and learn about apparently different kinds of Stubs, but Mocks are not Stubs…..

The article is a little bit lengthy but it is a good source of information if you want to, or have to learn more about testing, it also had a plenty of examples and explanations how the differences between stubs and mocks and dummies and fakes look like. When it comes down to it remembering these definitions from Fowler is the minimum of work:

  • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
  • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
  • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
  • Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
  • Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

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.

Stubs

When it comes to testing software I am definitely all for it but at the same time I am for it by doing it the “old school” way. Even at work this mentality stands, but recently the more I learn about testing the more I understand the need for it.

Having learned more about the subject of testing I feel like I can talk a little bit about it. Stubs is the part I been educated on recently and it is a bit confusing but that will probably go away with time and practice. Anyway Stubs. Those in programming are (according to Wikipedia): a piece of code used to stand in for some other programming functionality. A stub may be a temporary substitute for yet-to-be-developed code. I do know how to use those but until now I didn’t know what they are called and that is cool in its own way. Everybody knows how to use some fake code that is there just to run something for a time or to fool rest of the code into working. Now you know what to call it to. A STUB!!!

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.

Displaying JUnit Test Reports on GitLab

In this blog post I wanted to look at something interesting that I found a while back this semester when we were learning about JUnit testing and combining this with GitLab. In class we learned how to use Gradle to build our Java programs and to run JUnit tests and get GitLab to run them when we pushed our code to GitLab using GitLab’s continuous integration feature. As GitLab’s documentation says, using Gradle and JUnit on Gitlab will show whether the tests fail on GitLab, but I wanted to take this a step further and looked into seeing if it was possible to display more information about JUnit test statuses on GitLab itself. This led me to finding this article in GitLab’s documentation about a feature in GitLab that can display JUnit test reports on merge requests. As this documentation shows this can easily be enabled on any GitLab project that already is a Java project with GitLab’s CI using Gradle to run JUnit tests. All you need to do is add the necessary lines in the GitLab CI/CD config file provided in this document to display the tests reports in a merge request.

I already tried this before a couple of months ago when I first found it, but I wanted a nice demonstration of this feature, so I created a little Java test program that has a basic Student class with a JUnit test class. I then converted this to a Gradle project using some previous programs we have used as examples and instructions provided from this class and then pushed this to a new GitLab project. On the master branch of this project the tests pass as indicated by the previous GitLab CI job. After getting the initial code pushed and passing the tests, I then created a testing branch where I changed the code in the Student class so that one of the tests (testSetLastName) would deliberately fail. Creating a merge request on GitLab for this branch and pushing this “broken” code results in the test failing when it runs on GitLab with Gradle and therefore GitLab displays on the merge request which JUnit test(s) failed:

blog-post-1-screenshot.PNG

I found this little feature to be pretty awesome in combining software testing along with software management tools and can easily see how this would be very useful for checking if new or modified code in a project causes tests to fail. In addition to checking if the tests pass, this feature allows us to easily see which tests fail, and directly on the merge request itself, instead of the alternative that the documentation says of looking through reports possibly containing thousands of lines for the failed test. I will definitely be implementing this on any projects I’m working on that use JUnit tests and are hosted on GitLab.

Link to article: https://docs.gitlab.com/ee/ci/junit_test_reports.html

Link to demo program: https://gitlab.com/cradkowski/gitlab-junit-test-reports-demo

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Testing, Testing and some more Testing

In my Testing class we are constantly learning some new techniques and ways to test software, although there is some hands on testing on actual code a lot of it is more theoretical or to be more specific it is describing how we can test. It is all useful I know it but as a CS major I do want to write code if possible, less theory please, more practice. End of rant? Maybe for now.

This week was about Define-Use Testing. It is somewhat simple concept and I am glad that I can learn about it. It showed us some of the ways that today’s compilers work and make comparisons to display errors in the code. The whole concept of Define-Use testing is all about visual inspection and checking of the code. This will be some useful information for certain aspects of Computer Science field.

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.

Learning with POGIL

This is going to be my second semester with POGIL (Process Oriented Guided Inquiry Learning) style classes and I have to admit I am a fan. The classes are a lot more involved for students and in my opinion it makes it a lot more interesting and helps with retaining information about topics.

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.

Technical Interview Tips

Summary

In the article 5 things you need to know in a programming interview, Zhia Hwa Chong gives some useful tips for those starting their programming careers or those who are preparing for an interview. A quick summary of these tips are as follows:

  • “Always Think Ahead” – Referring to making sure when solving a problem to always look ahead and think about potential improvements. For example, he specifically says to think about edge cases, scaling issues, problem areas, and other topic-specific issues (e.g. handling collisions in a hash table).
  • “There’s more than one answer” – Each interview problem always has more than one solution, however, some of these solutions may not be optimal. It’s important to be able to write a working solution, but you should also look to improve upon it.
  • “OOP is not dead” – Make sure to think object-oriented (e.g. don’t cram everything into one method, don’t reuse code, etc.). Following these practices creates cleaner code, simplifying the code and makes it easier to understand.
  • “Craft your résumé” – Make sure to not skip preparing a great resume.
  • “Communicate early and communicate often” – Talk through the problem with your interviewer so they can understand your thought process and push you in the right direction.
  • “Use abstraction” – Using abstraction to hide complicated implementation details creates clean and easy to understand code. Afterwards if requested, you can implement any abstracted details.

Reaction to Content

I chose this topic because it’s something that is currently very relevant to me, as I’ll be graduating next May and hope to get something lined up before then. I had already seen many variations of these tips before, but I think reading this is useful for reinforcing them. While not necessarily applicable to all interviews, most popular tech companies follow the white-boarding process that this blog is giving tips for. For anyone looking to work for any of those companies, following these tips would definitely be valuable. However, they only cover things you should do during your interview, not topics that you would need to prepare for long before it, such as data structures, algorithms, general problem solving skills by solving similar problems, etc.

 

Source: https://medium.freecodecamp.org/the-most-important-things-you-need-to-know-for-a-programming-interview-3429ac2454b

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Graph Theory

Summary

In the article A Gentle Introduction To Graph Theory, Vaidehi Joshi goes over some of the basic concepts in graph theory, such as the difference between trees and graphs, undirected graphs vs. directed graphs, vertices and edges, and unordered vs. ordered pairs in graphs. She also provides great illustrations for the differences between each of these topics.

Later in the article, there are great real-world examples of what graphs are used for. For example, she talks about how two different social networks, Facebook and Twitter, are each different types of graphs. In this case, Facebook is an undirected graph because a connection on Facebook has to be a bidirectional connection. Twitter, on the other hand, is an example of a directed graph, because you’re able to “follow” someone without them following you back, meaning it can be unidirectional. The other example that she used that I found useful was comparing the web (traversing between web pages) to one big graph. So as you navigate back and forth between different URLs, you’re just navigating throughout one massive graph. For example, each article on Wikipedia contains key words that link to other articles, which could even potentially lead back to the original article.

Reaction to Content

I chose this topic because I wanted to get a quick refresher on it. While I’ve been exposed to this type of data structure before and seen some of the algorithms used for traversing through graphs, I haven’t really used them outside of coursework. Also, I feel as though I didn’t really have a great understanding of this topic until now. Seeing the examples provided in the article of real world applications of graphs I think was very useful for me to understand their purpose.

Overall, I think this article in particular is a great introduction to graphs, going over basic types of graphs and the concepts needed to understand them. While I already had a decent understanding of graphs, it was useful to reread some of the concepts and reinforce my understanding of them. However, there are many more topics that are important to grasp in order to understand graphs fully, such as the different types of traversal algorithms used for graphs as well as other different types of graphs like weighted graphs or trees.

 

Source: https://medium.com/basecs/a-gentle-introduction-to-graph-theory-77969829ead8

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.