For today’s blog I will be discussing the topic of testing with mocking. I recently read an article called “Mock? What, When, How?” by Lovis Moller. So let’s jump right in. What is mocking in terms of testing? Think about your code as a giant puzzle. All the pieces fit together, but they fit together in specific ways. Say you’re missing a piece of the puzzle because your partner hasn’t finished their part of the code yet. The new problem is this: how can I test my code without my partner’s piece of the puzzle? The answer is by using mocking. Mocking allows us to emulate or “mock” our partner’s puzzle piece that we are missing so that we can test our code without having to actually have the rest of the puzzle pieces. So mocking seems like a pretty good idea and like something we should use all the time, right? Wrong. The article talks about some of the pitfalls of mocking, which we will now talk about. First, the article says to mock only code you own. Do not mock third-party code simply because it’s not yours and you do not know how it works or how it should work. Another rule of thumb is to avoid mocking values and concrete classes. You should avoid mocking values because the objective of mocking is not to test for specific values, but rather it is meant to test the relationships and interactions between different classes (pieces of the puzzle). Concrete classes should not be mocked because of all the extras (methods, unused lines of code, etc) that come along with the  concrete class. It is more efficient to use mocking with an interface in this case.

In the past few weeks we have been doing testing with mocking in our CS class. I think it is a really neat and useful way to test because you can get stuff done on your end without having to wait for someone else to finish. In a world where we work as groups to complete projects, human error is always an issue. We could have our parts of the code done weeks before a deadline while our partner waits until the night before the deadline. Problem here is that we might not be able to proceed in testing and fixing our code because what our code does as a function relies on our partners code. We certainly do not want to wait until the night before a deadline to test and fix everything. Mocking helps us with this by emulating the code we are dependent on. I hope to use this more in the future.

Here’s the link to the blog: https://blog.codecentric.de/en/2018/03/mock-what-when-how/

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

This article from softwaretestingmagezine.com talks about how testing and monitoring live and active services is a key element of software quality assurance. After deployment, making sure all of the bells and whistles of a service are up-to-date is a very important thing. Not only is it important on the programmer’s end, but it is extremely important on the client side because you should have a smooth experience for the both of you. Without proper testing of a product or service, it is impossible to correctly gauge how it will perform, which is why pre-launch and post-launch immanence testing is a must, especially today. This article then goes into many online services that monitor performance and uptime of certain services. Let’s go into some of these now.

A very important aspect to tracking a service is by recording it’s uptime. A service called “StatusCake” does just this. StatusCake is a paid monitoring service that can monitor page speeds had extremely high rates. They claim to have a very large system for monitoring big servers. Another nice thing about StatusCake is that it can set reminders about domain renewals. SSL monitoring, and much more. Although at may seem like monitoring uptime of your service wouldn’t make sense, it is actually very crucial in many ways. One thing I learned from this article about how important this is, is by monitoring your up time, depending on how long a service is kept online without failing, you can determine by logging where issues lay when something does occur. Something such a service outage or service lag can easily be tracked and tested if you have tools available to help you track it.

Tracking these issues with a system can be tricky, but there is another testing tool that can help us do exactly this. This tool is called Uptrends. Uptrends is another software testing tool that actually notifies you and double checks when something is wrong with your service. One of the harder things is tracking exactly when or where an error in a service occurs. The interesting thing about Uptrends is that it will actually give you detailed reports and statistics on these errors and also sends out email alerts when something goes wrong. This is another very important aspect of software quality assurance and testing. When something goes wrong you need to have information about the failure as fast as possible. With services such as this, you can receive notifications as soon as the fault happens so you can act accordingly to the issue.

Many services are available to help developers and clients for software testing and quality assurance. Depending on what you need, it is very important to keep a close eye on operations after a service is launched or completed, especially if it is being upgraded or modified in any way.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

https://www.qualitylogic.com/2018/01/11/closer-look-integration-testing/

Integration testing is the process of assembling various code modules to preform very specific tasks in a software system that uses them in a more generalized application. The article gives the example of using a module that stores and retreives files with another that displays their names in a list and another that reads keystrokes as well as one that that recognizes mouse clicks, all together it is a file manaement application. Each module is usually created and tested seperately using unit tests before being added to the code control system. After in the management system they are subjected to integration tests which tests them in conjunction with other modules. This usually uncovers issues with data formats, operation timing, API calls, database access and user interface operation.

There are four parts of integration testing that are critical. The first one is software integration which means in part that everything fuctions the way the user commands. For example, with interface operations it is important that when a user does something unexpected by the systems design the application does not simply crash but produces an error message. Next, the modules must continually exchange data as the overall system functions. This is often performed by a data or command bus that facilitates module communication. These buses are often the most stressed component of the system and integration tests should test them under various amounts of load to ensure that the individual modules are working together properly. Third are the API calls which are the most common channel by which the system communicates with third party services and has become a tool for connecting modules together within the system. This allows data and commands to be separated into different function calls making the exchange easier to debug. One of the main issues with API calls for integration testing is that each one needs to be tested separately, through the entire set of data and inside and outside the acceptable range. Then API calls must be tested in functional groups. Finally there is End-To-End testing which is a big priority for integration testing. The test sets up a system called a sandbox environment and then creates tests for every use the application would go through in real world use. User inputs simulate the front end with data and requests which are then communicated to the middleware to work with the backend of API calls to third parties and database manipulations. All of this is carefully monitored for accuracy and run time.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

When someone relies on you in a project, for work or in any other situation, sometimes you realize you do not know how to use a particular tool or technology required. Your coworkers or manager need to have confidence when you are assigned a task, but if you tell them you are unfamiliar with the technology required to do the job, would they not lose that confidence in you? But you can not lie either, of course. What do you do?

Tell them anyway, show them that learning is an unavoidable part of software development and no one can be familiar with every piece of technology out there. If you have to reassure them that you can complete what is needed of you, do so with your ability to learn. Let them see your growth throughout your career. There is an ingrained instinct in most people to appear competent, and to do otherwise goes against that instinct. It can also be a matter of pride, not wanting to look ignorant.

But it has to be done. Exposing ones ignorance and marching on is part of the process and leads to much more growth overall. It allows others to aid you as well and lets the team act as a team. I myself have trouble doing this, so this pattern was an important and difficult one for me to read. I have had trouble admitting ignorance in the past, and while it has not hurt me, it definitely did not result in me learning anything new or fixing my ignorance.

While I have not taken the exact actions described in this pattern, I have made an effort the last year or so to ask questions when someone mentions something I am ignorant of. Instead of going with the flow and letting my ignorance pass by undetected, I try and use it as a moment to learn something new. Exposing my ignorance publicly as the pattern suggests is a bit more daunting. I already do that somewhat implicitly in my blog posts, but I guess I should start doing it explicitly as well. Wish me luck.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

In this Apprenticeship Pattern “Nurture Your Passion”, it explains the the importance of your passion as a software developer and how it can be exposed to situations or circumstances that can affect to maintain that passion. This pattern illustrates various ways to protect and keep that passion healthy as possible in order to prolong the enjoyment of being a software developer such as:

1. Work on what you like.
2. Join a local or study group that enjoys and focuses on the same things that you enjoy or want to learn more about.
3. Read books that can expand your view of the field.
4. Create your own path or move into an organization where your needs, asprirations, and goals can come to fruition.

“Paul Graham said, “The key to being a great hacker may be to work on what you like…. To do something well you have to love it. So to the extent that you can preserve hacking as something you love, you’re likely to do it well.”

This statement by Paul Graham was very interesting and useful to me because for me as an individual, I produce the best work when I love and enjoy what I do. There have been some instances of my life where I would not produce my best work where my state of mind does not like what I am currently doing, whether it be a class that I am taking at school or a part time job.

“To become a journeyman, you will need to have a passion for software craftsmanship. Unfortunately, your daily activities often work to diminish this passion. You might be faced with demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues. It’s hard for your passion to grow when exposed to such hostile conditions, but there are some basic actions you can take to sustain it.”

This is another statement that I found useful and will help me in my intended career because I understand at the end of the day, work is work, and there will always be times where deadlines, corporate needs, managers and co-workers will stress me out, which will lead to a decrease in my passion for software development, particularly video game development. However, the actions that I’ll take will help reinforce my passion to sustain the harsh natures of the work environment and to prolong my love to hone my craft.

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

For this weeks pattern I wanted to understand and analyze “Retreat into Competence.” This pattern addresses the issues of an individual feeling overwhelmed about not having enough knowledge or experience to tackle a project. In my experience in computer science, this happens almost every time I am introduced to a new project or concept. In… Continue reading Apprenticeship Patterns: Retreat into Competence →

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