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.

Designing in Git?

When it comes to software, and working on it as a team, or sharing it with others, Git is the bread and butter of it. That is what class is centralized around, learning how to use Git, and how it benefits you and others. At first glance, it appears difficult. After understanding its role in the greater scheme of things and putting it into practice, it’s not all that hard. Originally, I thought Git was another coding language, like Java. I was wrong, as it’s like Bash, but unique in its own way. It allows people to create code, share it with others, where it can be used, changed, and reshared with others, where the same thing can happen, making branches of code different from the last.

To use Git, you need a code hosting platform, like GitHub or GitLab, and a code editor, like VS Code. You don’t need to use these specific sites or editors, as each is similar and unique. Once you have these, you can start writing your code, stage it, commit and push it into your code hosting platform on the internet for others to see, use and change. Or you could fork some code and change it up however you want, stage, commit and push it back and see what others think. Git allows not only teams to work on code together, but strangers too, from all over the world. 

But who says Git can only be used for coding purposes? In this blog post, by Bruno Brito, they describe how Git can be used for designers, as in those creating graphic design and photo editing. They describe what Git is, how it is used, how to use it, and other things needed to know as a beginner to Git. However, instead of editing code, they use photo editing software. They describe how to create repos, how to stage and commit, and then how to use cloud-based hosting platforms to maintain synchronization. Then they go on to describe forking, cloning, pushing, pulling and branches. 

At quick glance, this could be interpreted as a tutorial for Git, which it is, but set in a setting different from coding, specifically for design. I like this post because it shows that Git can be used for other fields, similar to my last post. I find that these ways of organizing code, among teams and many people, efficiently, and it allows many people to chip in, and upload their work. Although the post to me is essentially useless, as I have already learned how to do Git, it can be helpful to others who are looking for ways to create an efficient work environment. I can relate to this, as a communications student also, I am somewhat fond of graphic design. I may not use Git if I am creating work on my own. But in a team, keeping track of who is doing what, and what changes have been made to artwork, it can be helpful.