Category Archives: Week 10

Week 10 Blog Post

Searching for an article this week I looked for something relating to mocking. Considering last week I did the negatives on mocking I think it’s valuable to have various perspectives. Seeing multiple ideas with mocking can give us an idea of how to implement them in the future. The writer of this article is a reliable source being a Java script developer. Getting information from someone in the industry can give a perspective inside the workforce and how people inside see different ideas. Not everyone may agree with using the same coding language but seeing how developers see different concepts can give an idea of the drawbacks to stuff and where in our own experiences can we improve. Overall this article is a great way to see how mocking is seen inside the workforce by an experienced professional.

In this article, Eric Elliot focuses on the drawbacks of excessive mocking. He points out how brittle tests and how they can be easily broken. There broken simply just from the change of implementation even though the behavior stays the same. Another point is a false sense of security because of there lack of accuracy that occurs from not using accurate real behavior. This is a fault in the test because the test will pass even if it isn’t supposed to. Third, he focuses on complexity overload which is just adding too much complexity can make the code harder to understand and maintain. Elliot still believes in mocking but a more balanced approach can overall help the program. Mocking should be used sparingly and when there actual weight for its use. All together Elliott wants the audience to create a strategy that will have confidence in their code correctness while also minimizing any negatives of excessive mocking.

Reading this article at first I thought it would be more of a pro mocking but it’s more in between. It says its flaws while still sharing the positives. After reading this article I understand that mocking can cut time but it can bring flaws to testing. The best time to utilize mocking is when time is scarce and later it can updated with time. It still isn’t the ultimate be-all to testing but with a balance, it will work. Understanding these flaws can foresee issues that may come up when mocking. Mocking should never bring up complexities that can complicate the code and should always have a priority in simple to understand and easy maintenance.

View at Medium.com

https://medium.com/javascript-scene/mocking-is-a-code-smell-944a70c90a6a

From the blog CS@Worcester – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Understanding Software Test Doubles

Dummies, Stubs, Spies, Fakes, and Mocks

Software testing is a crucial component of the software development lifecycle, ensuring that your application functions correctly and meets user expectations. One of the key concepts in unit testing is the use of test doubles, which help isolate the system under test (SUT) by replacing its dependencies. This isolation is essential for creating effective and reliable unit tests. In this blog, we will delve into the different types of test doubles: Dummy, Stub, Spy, Fake, and Mock, and explain their roles and usage with examples.

Dummy Objects

A Dummy object is the simplest form of a test double. Its sole purpose is to fill parameter lists without actually being used in the test itself. Typically, a Dummy can be a null object or an instance with no real logic, used just to satisfy method signature requirements. For instance, when testing a method that requires an interface which the test doesn’t interact with, you could pass a Dummy implementation of this interface. However, a Dummy should never affect the test outcome.

Example:

In this example, dummyBoard is a Dummy since the test does not interact with it beyond instantiation.

Fake Objects

Fakes are more sophisticated than Dummies. They have working implementations, but usually take shortcuts and are simplified versions of production code. Fakes are particularly useful when testing interactions with external resources, like databases. Instead of connecting to a real database, you can use a Fake object that simulates database operations.

Example:

Stubs

Stubs provide canned answers to calls made during the test, usually not responding to anything outside what’s programmed in for the test. They are used to supply the SUT with indirect input to test specific scenarios.

Example:

Mock Objects

Mocks are used to verify interactions between the SUT and its dependencies. They can assert that objects interact with each other in the right way, making them a powerful tool for behavior verification.

Example:

In this case, mock is used to ensure that the Module correctly logs messages when an exception is thrown.

Spy Objects

Spies are similar to Mocks but are used for recording information about how they were called. They can be used for more complex scenarios where you need to assert that certain methods were called a specific number of times or with certain parameters.

Example:

Here, spyLogger acts as a Spy, recording the number of times Log was called.

Understanding the differences between Dummies, Fakes, Stubs, Mocks, and Spies and when to use each can significantly enhance your unit testing strategy, leading to more maintainable and robust code. While these tools offer great flexibility, remember that the ultimate goal is to write clear, concise, and reliable unit tests that effectively cover your code’s functionality.

https://dipakgawade.medium.com/mocking-for-unit-tests-understand-the-concept-221b44f91cd

From the blog CS@Worcester – Coding by asejdi and used with permission of the author. All other rights reserved by the author.

Mocks and Stubs

Testing is an important part of coding, and software development. Sometimes though, testing can be tedious work, and creating tests that work properly according to your code can be difficult. This should be the case anyways, as testing is a key aspect to software development, but what if you could do this process a bit more quickly. Creating mocks and stubs can be a good alternative, especially if multiple people are working on different parts of the same project or software.

In this blog post, June Jung touches upon mock and stub testing. They describe mock testing as “creating a fake version of an external or internal service that can stand in for the real one,” and stub testing as “creating a stand-in, but a stub only mocks the behavior, but not the entire object.” The whole idea of mocks and stubs is to create a fake or a stand-in that does not do anything. This may seem strange, having completely useless methods and functions, but the thing we want to test for is the interactions between the methods and functions. Seeing whether or not they return the correct return values, call the correct methods, etc. This will reduce the amount of time needed to test the functions, compared to testing full, complete functions and methods. Jung says that by using mocks and stubs, you can “reproduce more complex scenarios more easily. For instance, it is much easier to test the many error responses you might get from the filesystem than to actually create the condition.” Jung says this specifically for unit + component testing, but this principle can apply for any kind of testing. In fact, they touch upon multiple cases where mocks and stubs can be used, such as internal functions, integration testing, and contract-based testing. They also provide code examples, and graphs to help you visualize the concept, which can be helpful.

Jung says that as your code grows, your tests should as well, meaning you shouldn’t continue to use the same tests as you continue to write more code, losing the mocks and the stubs. That being said, they’re good to help start, providing a base to continue with. Jung’s blog post is a good resource, as they also have linked another post that goes into the difference between mocks and stubs. It also appears that their blog post is part of multiple posts, which may be worth looking at for more information.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

copyright licenses

We’ve covered software licenses a fair amount in our Software Process Management course. The MIT license, Apache License, and GNU GPL were the most notable for different reasons, but I figure that there are far more licenses that we haven’t necessarily gone over directly in class. I wanted to take the time to familiarize myself with some of these licenses.

Starting off with a CopyLeft license (a type of license I find myself fairly sympathetic to for the sake of keeping software open source), the Mozilla Public License, or MPL, is a weak sort of CopyLeft. According to this post on fossa.org, this means that users must disclose changes, but for a much narrower set of code for each change, file-based for short. When compared to the LGPL, a notable weak copyleft license, the MPL allows users to sublicense as an additional permission. Notable uses of this license are, of course, Firefox and Thunderbird, along with LibreOffice. I do like the idea of having a middle ground between being completely permissive and also wanting to “spread” open-source.

BSD Licenses are permissive licenses that generally have no restrictions. This license seems to fall in line with the big permissive licenses (like MIT) and doesn’t have a viral effect, but requires a copy of the license and a disclaimer of liability. According to a post on AppMaster, the differences between the MIT licenses and the BSD licenses is there being no requirement for a liability disclaimer for the MIT license, no requirement for patent protection on the BSD license, the BSD license being compatible with GPL, and the MIT license requiring a permission notice. I don’t like the lack of patent protection with this one, I know that’s been a fairly annoying issue in the past for various projects.

Lastly, I took a look into the OpenSSL license, as it was on the front page of tldrLegal. Funnily enough, it’s a license styled off of the BSD license, with the express purpose of being used with the OpenSSL project. On the aforementioned tldrLegal page for the license, it mentions in the summary that the license has a special advertising clause, which means that ads mentioning the software in any way must acknowledge the use of OpenSSL. The takeaway, for me, is that if you know exactly what you need with your license, and one that exists has everything you’d like except for one specific requirement or permission, you can build off of that license with that added requirement or permission (assuming that you have a legal expert of some sort write it, I’m assuming).

Overall, I really appreciate the work that has been done to ensure that we have a variety of different ways to license our software depending on what we want done with it. It’s definitely an important aspect of open-source development, and having the resources to find licenses that are closest to the project’s vision is an excellent way to focus on the development and not have to worry about the legal stuff.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

Git and Game Development

A subject that has always been near and dear to my heart is video games. Throughout my life I have always been deeply enamored with games and the process of their creation, from the intricacies of 3d modeling to the various game engines in use. Despite that, I would not say I am an expert in modern game development by any means. As my classes have progressed however, I have begun to understand more about the inner workings of software development and how teams are managed. This led me to investigate how game developers use these tools to manage projects and keep everything orderly. After doing some research, I found that many game engines are compatible with git and have no issue being stored on GitHub. Not only that but prominent game engines like Unreal Engine even have their source code up on GitHub, available for anyone to fork and clone. This was done to allow developers to modify the game engine itself, for whatever purposes they need. Godot is a free open-source engine that uses the MIT license and is also entirely up on GitHub. Of course, even if an engine does not have their code on GitHub or Gitlab that does not mean you cannot just host your code in an online repository. Thanks to what I have learned this semester, I can now make use of GitHub in the creation of repositories for any game projects I have.

It is not enough to learn about how game developers make use of git, project management is also a vital tool for game development. In terms of project frameworks, agile methodologies have seen widespread use within various industries, including the video game industry. Scrum is the most prominent of these methodologies and has been adopted by various companies. Due to the nature of video game development, there is a greater need for cross-disciplined teams comprised of developers versed in various skills. Game development can be effectively chopped up into tasks that fit nicely into each increment, for the medium itself necessitates a functioning step by step pipeline. Level designers cannot do anything without the assets created by artists and so on and so forth. The first couple sprints would work on creating functional assets like 3D models, textures, and game mechanics. The goal of each subsequent sprint would be to create a functional game section by section. I hope to one day make use of scrum and help create a game of my own.