Category Archives: Week 13

Test Doubles — Fakes, Mocks and Stubs.

Capture1We are looking at testing with Fakes, Mocks and Stubs. A Test Double is automated testing it is common to use objects that look and behave like their production equivalents but are simplified. This reduces complexity, allows to verify code independently from the rest of the system and sometimes it is even necessary to execute self-validating tests at all. The three implementation variations of testing doubles:

Fakes are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code. Fake implementation can come handy for prototyping and spikes. We can quickly implement and run our system with in-memory store, deferring decisions about database design. Another example can be also a fake payment system, that will always return successful payments.

Command Query Separation- Methods that return some result and do not change the state of the system, are called Query. It returns a value and is free of side effects. There is also another category of methods called Command. This is when a method performs some actions, that changes the system state, but we don’t expect any return value from it. For testing Query type methods we should prefer use of Stubs as we can verify method’s return value.

Stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects. An object that needs to grab some data from the database to respond to a method call. Instead of the real object, we introduced a stub and defined what data should be returned.

Mocks are objects that register calls they receive. In test assertion we can verify on Mocks that all expected actions were performed. We use mocks when we don’t want to invoke production code or when there is no easy way to verify, that intended code was executed. There is no return value and no easy way to check system state change.

There are more test doubles such as dummy object, test spy. I thought this blog show clear each test and simple example.

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


Hello dear reader. Another concept that I came across this semester in my Software Design and Construction class was UML diagrams and I wanted to write about UML diagrams in one of my posts.

For all of you that are new to UML, UML is not a programing language. UML stands for Unified Modeling Language. UML is a standard model language of an integrated set of diagrams. UML was developed to help system and software developers for specifying, constructing, visualizing, and documenting the code of software systems. It is a very important part of developing object-oriented software and the software development process. UML uses mostly graphical notations to express the design a software. Using UML helps teams communicate and validate the architectural design of the software. We use it to portray the behavior and the structure of a system/project.

A question that I asked myself when I started to learn about UML was: Do we really need UML? The more I learned about it the more I understood how important UML is. This for different reasons like: – there are a lot complex applications and systems that need planning from a lot of different teams, and clear explanation need to go to each and every team working on the same project; most of our users might not ever know what code is, but there are a very important part of our project and that’s where UML kicks in by translating this ‘foreign language’ called code.

UML can be classified in two types: Structural and Behavior Diagrams. Structural Diagrams get the static aspect or structure of a system. It includes Object Diagrams, Deployment Diagrams, Class Diagrams and Component Diagrams. Behavior Diagrams on the other hand get the dynamic aspect or behavior of the system and it includes Interaction Diagrams, State Diagrams, Use Case Diagrams and Activity Diagrams.

Except school I have come across UML Diagrams at my job too. The diagram I have seen and that we use a lot if the Deployment Diagram as each of us should be aware of the architecture of the system as deployment.

I like the way Noel explains UML diagrams and where/how to use them. He provides great graphic examples of the diagrams.

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

Test Coverage

Raw Coverage vs. Meaningful Tests If you’re shooting for a high-coverage number at the expense of a solid, meaningful, clean test suite, you lose value. A well-maintained suite of tests gives you confidence in your code and is even the basis for quickly and safely refactoring. Noisy and/or meaningless tests mean that you can’t rely … Continue reading Test Coverage

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Nailing Code Reviews

The article How to Conduct Effective Code Reviews by Billie Cleek covers code reviews, when to use them, and what your objectives and goals should be when working on or submitting a code review. He discuses the different roles you can take in a code review (which are almost analogous to our roles in two of my classes this semester) and what you should expect to do while in those roles in the process of a code review.

A code review is basically a conversation between developers on a proposed set of changes to a project. It can be a discussion about why a certain part of the code is the way it is, whether or not something is effective, or if certain changes need to be made and how to go about that. Code review boils down to having a constructive conversation regarding the development of your project, and what changes might need to be made.

I personally have had a lot of trouble communicating difficulties and voicing my opinion in past classes. It is hard to find your voice and be confident, stating the issues you see and opening yourself to feedback, however through code reviews everyone who participates stands to gain knowledge from their peers as well as experience in effectively communicating to your colleagues. As long as you are able to give and receive feedback in a helpful but constructive manner, you can help clean up a project, fixing errors and making it clear and understandable for viewers to read.

In a way, I feel like my software classes this year have done a lot of work in preparing me for being effective in code reviews, as well as in the workplace in general. A lot of the important skills in code reviews are just as important in group work: effective communication, making sure questions are answered, and mutually agreeing on the decisions being made are all essential to having an effective and useful code review. Building these skills in general will make you a better team member, and help you work better in a group on big projects.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Version Control: A Primer

In her post A Gentle Introduction to Version Control, Julie Meloni gives a very easy to ready walk through of version control. Version control is all about maintaining the versions and revisions of your work as you are developing it. With good documentation, you can bring back old code you previously removed, or look at issues you had in your program in the past to see if that might be relevant to current issues. There are a lot of benefits to maintaining good version control.

Version control can also be useful in a classroom setting. I can recall multiple assignments this year where we used multiple commits with different labels for different assignment levels. In this way, the instructor could look at code from an earlier part of the assignment even when it had to be modified for a later part of the assignment.

Good version control also leaves you with backups if you want to revert to an earlier version of your program. Say you accidentally release an update with a major bug that slips through, you can quickly revert to an earlier version so you can fix whatever issues there are. You can use branches when you want to split off development into different directions and move the changes to main part of your program once you are satisfied, and you can use version control to help avoid any situations where there are conflicting commits.

I agree with Julie when she points out that version control has use in most business and private settings. Really, keeping good documentation of revisions of all documents can help organize your projects and keep them easily modified and reverted. For instance, if you are keeping a financial spreadsheet, but want to save it every month so you can track the differences over time, it is essential to use good version control to keep track of the revisions to the document. Or if you make modifications to a contract, but want to maintain copies of the older versions for legal reasons. Really, good version control is just part of good organization and allowing yourself to work with all the tools at your disposal. You work hard, there is no reason to throw it away.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Somebody Touched My Spaghetti!

For this weeks blog post I will be looking at an Antipattern known as Spaghetti Code from Source Makings site. Perhaps the most famous AntiPattern it has existed in one form or another since the advent of monogramming languages. Essentially Spaghetti Code is a very cluttered or messy design approach causing it to appear almost like spaghetti, all tangled up.

Nonobject oriented languages appear to be more susceptible to this, and this is more likely to occur to those who have yet to fully master advanced concepts involving object orientation. The general form of this spaghetti code appears in systems with very little software structure. “If developed using an object-oriented language the software may include a small number of objects that contain methods with very large implementations that invoke a single, multistage process flow. “.  On top of this object methods are invoked in a very predictable manner, with a negligible degree of dynamic interaction between any of the objects involved in the system. Causing the system to be very difficult to maintain or extend, allowing no opportunity to reuse the objects and modules in other similar systems. Spaghetti Code usually results in an inexperience with object oriented design technologies, similar to this no design prior to the implementation of the actual code. Another cause would be the result of developers working in isolation because of this their maybe ineffective code reviews.

A solution to this not so delicious mess would be through software refractoring (code clean up). This being an essential part of software development, allowing most efficient clean up. When the structure becomes “compromised” through the mess its support to extensions become more and more limited to the point of useless. Ideally code cleanup should be happening throughout the entire development process but that’s an ideal situation that not everyone (including myself) follow all the time. Doing so on an hourly or daily basis is a good start to this cleanup process.

If simple code clean up is not working what next? Stopping spaghetti code through prevention is usually the best way to resolve this matter. Before you start writing the code, have a plan of what you are designing and how to structure it. Commit to actively refractoring and improving spaghetti code whenever the code needs to be modified is an extremely useful to prevent it.

Essentially if you don’t want to have spaghetti and meatball code you need to think about the overall structure and a good idea of what you are going to be developing.

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

The Customer Wants What The Customer Wants

Hello, again my dear readers!

It appears that this week I am very focused on the customer this week as this article I read particularly focuses on what the customer wants. The article is titled, “Figuring Out What They Expected“. When it references they, the article is referencing the customer. The person you are programming the program or application for. Anyway, let us get into the meat of this article.

The article starts out defining two things. The first is what the user model is. The user model is effectively, what the user is expecting and thinking when they use the program. It bundles everything they know about computers and all their preconceived notions about using them when they sit down and use your program. How do I use this program and what does it do for me, the user? This is the model you are aiming to nail. If no one uses a program, does the program really exist? The answer is yes but we aren’t here to talk about that. The next model is the program model. This is what the programmer programmed into the program on how it looks, works, and operates. The idea in establishing this is that the user model and program model want to be overlapping or ideally mirroring each other. Now there are two ways to do this. The first is to change the user model. Good luck with that one. People are stubborn, stuck in their ways, and how would you even accomplish that anyway? Write a manual on how to use your program? We all know no one reads manuals anymore (although to be honest people really should) and if your program is different from what the user is used to, the user is likely to just not use your program. There is almost always another way. This leaves the program model changing to match the user model. I mean, let us face it, it might suck but you can change your program to match what the user will expect. It may be a pain but if it means your program is used more and ultimately bought more, I think it is worth biting the bullet.

The next part of the article goes over how to actually find that user model. The article has a simple and elegant solution… ask them. Then after you implement them, grab a few people and ask them to test them. Not a large group of people now. Only about 5 or 6 is required; after that, any more tests are fairly repetitive and not that useful. In the end, if the user has to guess how the program works, the program model is not quite there yet.

This article has reinforced my view that in this industry, the end user or customer is the ultimate determinant for a program or application. After all, we are programming an application for someone to use. If they can’t use it, its no good to them. I will admit, I’m surprised that only 5 or 6 people for usability testing are the norm. I do have a new appreciation for the Apple way of thinking where the simplest way to do something, is the way to do it.

Until next week readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Test Case VS Test Scenario

For this week’s blog, I chose to read the Test Scenario VS Test Case from the softwaretestinghelp website.

Test Case – a concept which provides detailed information on what to test, steps to be taken and what the expected result would be. It is more about documenting details. It’s important when testing is in another place than the development team. Easier to get the devs and QA team in sync. There is only a one-time documentation of all the test cases and can be easily tracked in the future. Test cases are also helpful to when reporting bugs. Testers have the reference to the case ID’s and do not require mentioning every detail of the case. It is also helpful to new testers since all the test are already laid out.  But it is time and money consuming as it requires more resources to detail everything.

Test Scenarios – a concept which provides a one-line information about what to test. It is more about thinking and discussions rather than listing everything. It is more important when you have a time constraint and most members understand what is happening.  It is better because it can save time and makes everybody think about what to test. A good test coverage can be achieved and it reduces repeatability.  But, if created by a specific reviewer or other users, they might not be in sync and cause confusions. This type of test also requires more discussion and team efforts.

I think this is a great read as it talks about the standard or old way of testing against the preferred testing by the new generation of software testing community. Test Case is the standard way of testing systems. While using a Test Scenario is new, it offers easier documentation when it comes to testing (assuming everybody understands what the system does). Although it seems like it is not beneficial since most companies change employees here and there, I can see test scenarios saving a lot of time just in the documentation. Learning about it opens up a lot of possibility in the way we think about testing but then again, there are already automated testing so test scenarios might not offer much in the future.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Dynamic Programming


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.


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

Sure You Can Test, But Can You Really Test?

Good day my fellow readers!

As I have been learning all about software testing in class, the career of software tester has looked more and more like a job I would like to do. In my readings, I can across a blog post titled, “10 Qualities That Can Make You A  Good Tester.” I know hat you are thinking, “Ugh! Clickbait list articles.” but this one seemed relevant so I decided to have a read anyway.

The post starts off asking the question, ” What makes you think you are good at testing? Why do you qualify as a tester?” The author was saying that anyone with enough knowledge can test a program. It falls to different qualities of the tester that truly make them a good tester.

The first quality is that the tester understands priorities. What should be tested, what should be automated, what requires manual testing, what should be done first, ect. You are given a thing(s) to test and you have a limited amount of time to test them. Prioritization is a must.

Next, the tester should ask questions. The questions go farther than just, “What is my goal?” They must deeper like what changed, what was fixed, what is the product used for, or who will use it. The more understanding a tester has, the better they can do their testing.

The tester must be able to create a number of ideas. There isn’t just one way to test one thing and one product may be used in different ways. Simply put, more ideas = better testing.

The tester must be able to analyze data. Not knowing what data you get back means you are missing a big part of your testing as much of automated testing is reading and understanding data.

The tester must be able to report negative things in a positive light and be good at reporting. These are technically two points but they are practically the same thing. Reporting something in a positive way, even if negative, is a great way to build solid communication and improve teamwork. This plays into good reporting. People want to hear straight and to the point reports that get the point across and all the important parts. No one wants to sit there and read a list of negatives for minutes on end.

A tester must be able to support the developer. This goes beyond just finding a bug for example. A developer can’t fix a bug if they are having a hard time even recreating it.

The tester can co-relate real-time scenarios to testing. This sounds like a lot but it really boils down to A.B.T. Always Be Testing. Almost like improve testing. If you constantly test thing in your life outside the office, it can give you ideas to test things inside the office.

A tester must be a constant learner. Like the rest of the programming industry, nothing stands still and you shouldn’t either. Learn new technology, new tools, and new ideas.

The last trait is the tester must be able to wear the end user’s shoes. The ultimate goal of the product is to send it to the end user. If the tester can’t understand the end user, the end user will most likely not be happy with what they get.

One big thing stands out to me after reading this list… the end user is everything. In just about every article I have read the end user will without a doubt make an appearance in one way or another. If I can’t get my head around what the end user wants, I will not last long as a tester. The co-relate real -time scenarios was an interesting one as I like most, probably leave work at the office and never take it home. This takes work and home and fuses them keeping the skill of idea generation at the forefront. What surprised me a bit was that the reporting skills were geared toward streamlined and quick reports. I had expected reports in the testing world to be longer and more technical. This may just be the writer’s individual experience but it does make sense to me. The people testers report to literally made the thing they tested. They probably don’t need a nitty-gritty teardown.

Now I have some things to work on as a programmer before I graduate. They don’t seem hard thankfully, just something that requires a lot of time.

Until next time readers, have a good day!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.