As I was doing some at home research on stubs and mocking for one of my courses, I came across the idea of spies. Unlike stubs and mocks which allow for the program and tests to run while giving canned answers or being unfinished, spies perform a much needed but previously unfilled role.

Spies are used to ensure a function was called. It’s of course more in-depth than this but that’s it’s basic function.

On a deeper level a spy can not only tell if a call to function was made, but how many calls, what arguments were passed, and if a specific argument was passed to the function.

Abby Campbell has great examples of these in her blog, “Spies, Stubs, and Mocks: An Introduction to Testing Strategies” where she displays easy to understand code. I would definitely recommend taking a look at them, her blog also goes in depth on stubs and mocking.

When writing test cases, the addition of a spy to ensure a thorough case can’t be undersold. Imagine a simple test case that uses a stub, without the use of a spy you can’t be sure the correct function was called unless every function returns a different value which would be inefficient to set-up. By using a spy the function called is checked, the argument passed is checked, and the output can even be checked as well leaving little to no room for an error in the test case aside from human error.

With the addition of spies to our arsenal of tools for software testing we check off the need to find a reliable way of testing for ensuring correct function calls and arguments. I plan on carrying this new tool with me throughout the rest of my career. It allows for much more efficient, effective, and sound testing.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

With an honors project coming up for one of my courses I was going to have to learn how to become a single person Scrum team. With the average scrum team being seven to ten people, I knew it was going to be both a strange and difficult task.

I knew my first order of business would be to create a product backlog as I am the product owner (among many other things being the only member of the team). Diving in headfirst, I knew what a product backlog was but not how to set up an effective one.

Thankfully, “A guide on Scrum product backlog” by Brianna Hansen was the perfect blog to stumble across. She eloquently states what a product backlog is, why one should be maintained throughout a project, and how to create a product backlog geared towards success. As an added bonus the end of the blog even provides a platform to create and maintain a product backlog.

As I previously stated, I’ve known what a product backlog is. It’s everything that needs to be done for a product, including maintaining it. As much as a product backlog is a to-do list, one way to increase success is to not overload it. Keep it simple but effective. No one on the Scrum team (in this case me) wants to scroll through a product backlog for hours.

Time management is crucial for a product backlog. Certain items contained in the backlog are going to be more time consuming than others so considering this when putting product backlog items into the sprint backlog is very important to sprint success.

Defining the product vision is one of the major points she gives for maintaining a successful product backlog. This usually involves the whole team getting involved to make sure the vision for the product is shared. While in my case I may be the only member Hansen does give some very important questions for me to ask myself when planning my product and adding items to the backlog.

• “What problem does the product solve?”
• “Who are the target users or customers?”
• “What unique value does the product offer?”

Taking these questions into consideration will help to guide me through this project and help to increase my chances of success.

Finding this blog was incredibly helpful for taking my first steps into trying Scrum firsthand and I intend to use what I learned as I navigate my honors project.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.