Category Archives: CS443

Writing Great Unit Tests

In the blog post Writing Great Unit Tests: Best and Worst Practices, Steve Sanderson talks about the best and worst practices when writing unit tests. He goes over the true purpose of unit tests (each examining a unit of your code separately and as a whole cohesively working together to provide value that is more complex and subtle than the sum of its independently tested parts, not for finding bugs), as well as the purpose of integration tests (automate the entire system to detect regressions). At the end of his post, he also gives several useful tips for writing great unit tests, such as making each test orthogonal, or independent, to all other tests.

The reason I chose to talk about this blog post is because I think it’s definitely something that’s commonly overlooked by developers. As Sanderson said at the beginning of his post, “Even if you’re a brilliant coder with decades of experience, your existing knowledge and habits won’t automatically lead you to write good unit tests.” For people looking to get into software development, I think it’s important to learn how to write great unit tests early on so as to avoid having to clean up a self-inflicted mess in the future.

I found it interesting when he described the difference between unit tests and integration tests, as well as the problems that bad unit tests can cause. This image found in his post is useful for visualizing this:

image

The last section in which he gives practical advise for writing great unit tests is also something that I think will be useful in the future, although I think the formatting may have been messed up.

One thing that I have a hard time not necessarily agreeing with but understanding is how he said that unit testing isn’t for finding bugs. I think that, for example, if you were to make a change to the way a function performs its task (perhaps to optimize the code) while not trying to affect the end result, one of your unit tests failing because of this could be classified as “finding a bug.”

Source: http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

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

Fakes, Mocks, and Stubs in Unit Testing

In the blog post Test Doubles — Fakes, Mocks and Stubs., Michał Lipski describes and implements three different types of test doubles: fake, stub, and mock, and the situations in which you would need to use them in your unit testing. He also provides useful examples for each of the three terms.

Here’s a useful image found in his blog that helps to understand the differences between the three:

Fake – object that has a working implementation, but not the same implementation as the ones in production. Usually they take some shortcuts are are simplified versions of the production code. This is useful because you’re able to do integration test of services without starting up a database or performing time consuming requests.

Stub – object that holds predefined data and uses it to answer calls during tests. This is useful when we can’t or don’t want to involve objects that would answer with real data or have undesirable side effects.

Mock – object that registers calls as they are received. This is useful when we don’t want to invoke production code or when there is no easy way to verify that the intended code was executed.

The reason I chose this blog post in particular is because the first time I was exposed to stub functions was earlier in my internship while working on unit tests, and at the time I didn’t have a great understanding of what their purpose was. I was recently reminded of them last week during lecture, so I decided that it’d be a useful topic to read about. At the time I wasn’t aware that there were different types of test doubles, so I found that the examples found in Lipski’s blog are really helpful in understanding the key differences between them, as they share many similarities and are likely to get mixed up. According to Lipski, misunderstanding and mixing test doubles implementations may influence test design and increase fragility of tests, standing in our way to seamless refactoring. So I think that this blog may be a useful resource if you were trying to write clean unit tests.

Source: Test Doubles — Fakes, Mocks and Stubs.

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

CS-443 Introduction

This is my introductory blog post for CS-443 Software Quality Assurance & Test.

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

The Software Craftsman Ch. 7 and Ch. 8

Chapter seven, entitled “Technical Practices,” covers the topics of ideal programming practices and why they should be utilized in the field.  Of course by best practices I’m speaking of TDD, CI, paired programming, etc.  These are the topics that have been covered at length in The Clean Coder and my related blogs.  I found it interesting that Mancuso has a separate section for refactoring outside of TDD.  For those who are unaware, refactoring is a step within test driven development.  Therefore, if TDD has been utilized, then there is no need to explicitly describe refactoring.

Chapter eight, entitled “The Long Road,” is an interesting chapter about career choices. We all know that money is a motivating factor when making career choices, but taking money out of the equation leaves you with the following three factors:

Autonomy: It is when we are in control of what we do, how we do it, and when we do it. That should always be the case in a true Agile context.

Mastery: It is when we are constantly learning and evolving—becoming bet- ter professionals and better human beings.

Purpose: It is when we feel that our job is important and we are contributing to make things better—instead of just doing what we are told without under- standing why.

Once we get a grasp on where we want our careers to go, and what factors motivate us, it is easier to find the right jobs.  This doesn’t just happen, it requires a lot of work and effort in order to “craft” our careers.  Mancuso thinks it is important to differentiate between a career and a career within a company.  Your career is more important than a career within a company.  I think that your career and your career within a company are equally as important, and should more often than not align, but then again I have not worked in the field.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Ch. 5 and Ch. 6

I was speaking with one of my professors today about Sandro Mancuso’s The Software Craftsman and was expressing my preference of this book to Robert C. Martin’s The Clean Coder.  I may have deluded myself into believing that Mancuso uses less anecdotes than Martin in his writings.  I am not infallible.  Mancuso does use an exorbitant amount of anecdotes in his book.

Chapter five is called “Heroes, Goodwill, and Professionalism” and after reading the chapter I’m still not sure I understand what the title means.  Goodwill does not even appear in the chapter.  This chapter reminds me of parts of a few chapters from The Clean Coder especially the chapter on “How to Say ‘No.’”  I’m not going to recap previous blogs so if you are interested in Professionalism I invite you to read my series of blogs on The Clean Coder as that is the theme of that book.

Chapter six is called “Working Software” and it is a pretty simple chapter.  Essentially the main idea behind this chapter is that if code is going to be used for any extended period of time, it must be written properly.  “Working software is not enough.”  Rushing through the process and skipping steps is going to cost you time later, so it is in your best interest to take your time.  Mancuso also describes how to address legacy code.  He points out that nobody likes working with legacy code, but a change in attitude can make a world of difference.  Isn’t that true of everything though?

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Sprint 6 – Learning Reflection

Sprint 6 marks the final sprint of our semester.  Our goal was to complete APTS-254 issue by the end the sprint.  The rest of our group ran into roadblocks and joined us in our endeavor.  We also hit roadblocks and needed more clarification.  Even though we found where in the code we needed to add the case, we weren’t positive about what the established reminders were doing.  So we determined that the only way we would be able to figure out exactly how these reminders worked was to recreate the scenarios in which they would appear.  Unfortunately, we were unable ETL server to work on our computers so we were essentially taking shots in the dark.

With all of this uncertainty, and the delayed response time from the people at Ampath, it was virtually impossible to accomplish anything of any substance.  In the end we were unable to complete our goal of finishing APTS-254, which means that we were only able to complete one issue this semester.  Perhaps I set lofty goals for our team, or maybe we underperformed, but one thing is for sure.  I can’t wait to spend way more time developing my own Angular 2 project.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Sprint 5 – Learning Reflection

Sprint 5 began with our solution to NGPOC-185 was pulled into Ampath.  We also started work on some new issues we assigned ourselves from JIRA.  In accordance with what we decided last week we picked two issues, one for each group of three.  Our group picked APTS-254 which was described as “User are requesting when a patient switches to 2nd Line the Viral Load Pop-up reminder should not pop until the patient has used the 2nd Line Regimen for 6 months.”  Just as we did with NGPOC-185, we decided the best course of action was to attempt to recreate the issue and then find where in the code the issue was located.  Neither individually nor as a group could the issue be recreated so we determined that we needed additional clarification on the issue.  I wrote a message to Ampath, but it took awhile to get a response, delaying our progress.  Before the sprint ended, we did get a response.  Apparently the issue was located in the ETL Rest Server, which we did not have before.  They directed us to the repository, but even with this new information we were unable to recreate the issue.  We will continue to work on this issue next sprint.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Sprint 4 – Learning Reflection

To start our fourth sprint we divided the NGPOC-185 issue into distinct parts so that everyone on our team could dig their hands into the issue.  We broke the task into six parts and everyone picked a piece they thought they would do best.  I was going to take everyone’s individual piece and combine them into the final solution.  Unfortunately, we were mistaken.  Our solution was incorrect because our approach was all wrong.  Over Spring Break one of the members of our group determined that the solution was much more simple than what we were attempting.  Once I returned from Spring Break, I had a chance to review his approach.  Apparently we were looking at the wrong thing and once we received some clarification the solution came together in a couple of days.

Screen Shot 2017-05-08 at 9.54.16 PM

Screen Shot 2017-05-08 at 9.54.30 PM

With our solution complete, we determined that these issues were not as complicated as we originally thought, and broke our group into groups of three.  This way we can complete twice as many issues per sprint.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Sprint 3 – Learning Reflection

This past sprint our class was assigned four issues on JIRA, an issue-tracking software. AMPATH set all of us up with our own login information so that we could view, assign, and comment on the issues.  The issue we wanted to work on was given to another group, so we ended up getting our second choice, called NGPOC-185.  The title of NGPOC-185 was “Logout not working when editing a form” and had the description “if you are in the middle of editing a form, but you decide to cancel and logout (may not be a practical case) , after accepting to cancel, it should log you out.”

As a team we determined that the issue was asking us to have a confirmation window pop up when a user tries to logout while they are editing a form.  So we figured our first step would be try to recreate the issue.  We booted up our local server and determined what the issue was describing.  Our next step was to find the code the corresponded to the issue.  After some searching we think we figured out where to begin.  We decided our best course of action was to read up on Materialize CSS and then attempt the issue next sprint.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 5 & 6

  • Test Driven Development [TDD]
    • Hammock-Driven Development [HDD]
  • Practice
    • Martial Arts of Coding
    • Open source work
    • Programming ethics

Many topics including the above are explored in Chapter five and six. Test Driven Development we all know and maybe don’t love. Or in my situation, having little experience with it. I would like to be able to pair program in the way that is described as randori. Alternating test and solution with a partner would be a frustrating yet fun experience.

I like the mention of HDD – Hammock Driven Development, it is the idea to step back and think about your work. Since we can run our code in seconds or less now, we should consider more than just quickly rushing through the motions. Luckily using a well design test suite makes much of this thought process easier. This is important to note that you would still need to take the time and come up with  all the test cases that accurately represent your specifications.

Practicing is something we know and do every day even if we do not realize. Slowly becoming more adept at our everyday tasks as well as specialized ones we preform. Practicing is something at coding requires in our day in age of frameworks, thousands of similar tools and of course the very basic coding syntax and style.

From the blog CSWSU – Triforce Code| Exploring and Learning by CSWSU – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.