Category Archives: CS443

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.

A* Search Algorithm

Summary

In the article Introduction to A*, Amit goes over two graph traversal algorithms: Dijkstra’s Algorithm and Greedy Best-First-Search Algorithm, providing a great visualization of how these algorithms work as well as cases in which they excel and in which they struggle. A summary of his description of these algorithms are as follows:

  • Dijkstra’s Algorithm – guaranteed to find the shortest path from the starting point to the goal, longer run-time because it visits vertices continuously expanding outward from the starting point until it reaches the goal.
  • Greedy Best-First-Search Algorithm – works with an estimate (heuristic) of how far from the goal any vertex is, selecting the vertex closest to the goal. Not guaranteed to find the shortest path, but runs much quicker than Dijkstra’s Algorithm.

He then explains what the A* Algorithm is, taking advantage of the best of both of these algorithms. This is done by combining the pieces of information that Dijkstra’s Algorithm uses (favoring vertices that are close to the starting point) and information that Greedy Best-First-Search uses (favoring vertices that are close to the goal).

Reaction to Content

This article is the first part of a larger series by Amit about pathfinding, however I believe that reading this article alone is good enough for a quick overview about what the A* algorithm is as well as providing excellent visualizations for the three mentioned algorithms. These visualizations are definitely helpful for understanding how these algorithms work as well as what their potential advantages and downfalls are.

I chose this topic in particular because it’s an interesting part of a subject area that I have interest in (game programming) and also is an important topic in CS in general (graphs and graph traversal algorithms). It’s a useful refresher for some of the topics that I learned in my algorithms course. Also, seeing how a potential algorithm in a game could decide how to best traverse towards a goal taking into account any obstacles in the way is interesting think about.

I think the rest of the series would likely be a good read to get a deeper insight into the A* algorithm.

 

Source: http://theory.stanford.edu/~amitp/GameProgramming/AStarComparison.html

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

Dynamic Programming

Summary

In the article Exploring Dynamic Programming, Ross Rhodes goes over three examples of dynamic programming in increasing difficulty: nth Fibonacci Number, Traversing a Matrix, and Matrix Chain Multiplication. These are problems that have straightforward but very inefficient approaches that can be solved via dynamic programming techniques such as memoization, which is an optimization technique that stores the results of expensive function calls and returns the cached result when the same inputs occur again. For example, in the case of calculating the nth Fibonacci Number for multiple different values for “n”, rather than performing those calculations again you can instead store already calculated values.

Although the three examples provided are each examples of dynamic programming, they each have moderately different approaches to solving their respective problems. As Rhodes says at the end of the blog post, these examples only scrape the surface of what dynamic programming can be used for.

Reaction to Content

I chose this topic for this week’s blog post because it was something I hadn’t been exposed to significantly. While I’ve known of the technique and its applications, I hadn’t used it for anything other than a similar application of the Fibonacci example provided. The other two examples provided are notably more complicated and helped to provide provide more insight into what situations dynamic programming can be used to solve.

Overall, while I think this article was useful for understanding dynamic programming, I think the best way to understand it is to solve problems using these techniques and to come up with your own solutions for them. That way you can really internalize these concepts and you can spot when you’ve run into a problem in which dynamic programming could be used. Just reading through these examples alone and trying to follow through the thought process won’t necessarily be enough when you have to solve a unique problem on your own.

I think this topic is definitely something that should be understood, as even if you somehow never ran into a real-world situation that dynamic programming would be useful for, understanding it will only make you a better programmer. And if nothing else, it’s likely to come up at some point in an interview.

Source: https://blog.scottlogic.com/2018/01/30/exploring-dynamic-programming.html

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