Category Archives: CS443

Test Precisely and Concretely: A Review

While much of the content was beyond my comprehension, I found Kevlin Henney’s article “Test Precisely and Concretely” article at Medium.com to be elucidating and enjoyable. Kevlin is known for his efficacious brevity in software and so it should come as no surprise that this translates to his writing. He comes right out of the gate with a strong opening sentence:

“It is important to test for the desired, essential behavior of a unit of code, rather than for the incidental behavior of its particular implementation.”

– Kevlin Henney @ https://medium.com/analytics-vidhya/test-precisely-and-concretely-810a83f6309a

While the first half of the quote describes the obvious end result that we as programmers are aiming to achieve, our desire to do write effective tests certainly doesn’t preclude us from making the mistake of the latter. There may be diminishing returns on the profundity of this statement but, as an amateur programmer who has only just begun to learn proper software testing, I’ve found myself writing software tests that give true outcomes but do not necessarily verify that the program itself performs accurate and verifiable calculations. For instance, when I was creating additional instances of an object in a recent assignment I was testing to see if additional objects were consecutively constructed in the sense that memory was allocated for it but I was not properly verifying that the objects upon their creation were given consecutive, uniquely identifying numbers which is where the real meaning of its creation lay. Simply put, it was the software testing equivalent of begging the question.

From my understanding, Kevlin’s prescription to the aforementioned issue is to understand that the conditions which are necessary for your test to pass are not always sufficient for their real use cases and born from this is the realization that programmers ought to more carefully examine the literal meanings of the postconditions they’re testing for. Furthermore, he states an accurate condition does not make for a good test, a “good test should be comprehensible and simple enough that you can readily see that it is correct.” In the spirit of the article, and perhaps even Kevlin himself, I will avoid verbosity and recommend that everyone check out what makes for a good software test here.

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

RefinementCodeReview: A Review

Go check out the original article here! It’s great!

In Martin Fowler’s blog post titled, “RefinementCodeReview” he emphasizes the need to rethink the frequency with which developers review code. He points out that pre-integration reviews and pull requests, while important, should not be vital to the development process in the literal sense of the word. Fowler highlights the etymological reason we have collectively acknowledged that software is accurately named; it is soft, and like all malleable mediums, should be worked through from end to end. Fowler seems to suggest that a shift in lexicon from architectural comparison to Erik Dörnenburg’s town planning one would pay dividends in inspiring more frequent refactoring of older code. While this seems obvious, it’s a powerful distinction; if we approach old code like a large stone monolith carved with divine intentionality rather than a living, revisable set of rules used to build and expand, then we are certainly adding unnecessary apprehension around the development process.

“As soon as I have an understanding about the code that wasn’t immediately apparent from reading it, I have the responsibility to (as Ward Cunningham so wonderfully said) take that understanding out of my head and put it into the code. That way the next reader won’t have to work so hard.”

Martin Fowler, 1/28/2021 @ https://martinfowler.com/bliki/RefinementCodeReview.html

I found this quote personally compelling but also particularly salient when Mr. Fowler addresses the dreaded, yet somehow inevitable, scenario where a high-threat vulnerability in the code is exploited. He calls these rare-high-impact concerns and yields that truly no amount of testing will ever eliminate their existence but the process of running continuous and vigorous testing can make accepting a certain amount of risk from older or inherited code much more palatable. While the author doesn’t mention this pattern by name, he implies that these good practitioners of efficacious refactoring, who are more knowledgeable of a code base, who are better still at creating self-testing code, who are better even yet at continuous integration would create a virtuous cycle of software development.

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

A Valuable Lesson for Creating Tests

Article link: https://dzone.com/articles/why-you-should-stop-now-testing-every-class

A great article I read today goes over the importance of creating the correct kinds of tests for software. In this article, the author thoroughly explains the importance of testing the “behavior” of software versus “implementation details” and how not “every single class” needs to be tested. I think the author does a great job with both an easy to understand narrative and tons of example code that illustrate the importance of testing that software performs to specification versus testing how the code is written. The example code given in the article goes further with linking to an entire GitHub repository for the example code (which elaborates beyond what is shown in the article) which I really appreciate as it lets me see exactly how this concept aligns with a complete program. The most interesting part of this article for me was in the author’s explanation of how refactoring code can cause tests that are written (incorrectly) to a specific implementation to fail. I think it is important to see this point that putting in extra effort in developing software but on the wrong things can actually do more harm than good further down the line. Especially as the author points out if you were to further refactor the code and change how it works (even return types as the author demonstrates!), this causes bad tests to fail, which only creates even more work. I never really thought of how refactoring could create more work in a testing scenario before reading this, but I like how refactoring further helps the overall program by exposing the appearance of useless tests. One other part of the article I really enjoyed was the side narrative the author gave while working through his example of how the steps they took followed TDD (test-driven development). This is also something I wanted to learn more about, and this article also provides a good example of TDD by explaining how certain practices taken in the code example adhere to the rules of this methodology.

Overall, I think this article covered an important topic well, and serves as a great reminder at the end of our testing course to make sure we are testing the right things in our software and that we are not creating too many, and useless tests that only hinder our efforts and not help us. I will certainly keep this article in mind when writing future tests to ensure I’m not wasting my time by creating the wrong kinds of tests or making sure every line is tested in a program.

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

Test Automation

Article link: https://dzone.com/articles/starting-automation-testing-from-scratch-here-is-w

Throughout this semester we have learned about how to create tests in a mostly “manual” way, today I want to explore an article that serves as an introduction and overall guide to automation testing. I especially wanted to learn about this topic since it has repeatedly come up in other articles I’ve read on this website.

Overall, I found the content of this article to be great and I think it thoroughly covers every aspect I can think of, and acts as a great beginner’s guide to this topic of automation testing. The author methodically covers everything on automation testing from the benefits of switching, to figuring out which areas of your testing should be automated.

Looking at the section of this article that lists the different areas automation testing can help is particularly interesting to me as most of the types of testing here I am unfamiliar with (and aren’t covered by our testing course) but would like to know more about. This includes areas such as regression testing, which I just learned about, and performance testing. From this article it seems that automation testing seems to help particularly with cross-browser testing. This made me think about how different web browsers are tested which is something I have only done by manually checking that the application functions properly by going through the program as a user. In retrospective it makes sense that some automated tool can make this much easier and I would like to see how this works more.

I think one of the most important points the author makes (and states many times) is “do not aim for a 100% automation”, which makes sense as the author explains how it is not necessarily feasible or beneficial to have all of your tests automated. Furthering this point, the other interesting part of this article is how the author explains that manually testing is better for certain aspects of software. After reading these reasons, I completely agree with the author that certain areas such as testing the actual user experience of a program makes more sense to test manually instead of automating. Another aspect I really like about this article that I like is that the author continues throughout the article to focus on the practicality of automating testing from a business standpoint and takes into account the amount of investment and return on investment that can be gained by automated testing.

This article has certainly made me more interested in testing automation and I would like to see how tools implement this, especially in areas the article says can really benefit from this such as regression or browser testing.

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

A Retrospective and Review of Unit Testing

Article link: https://dzone.com/articles/why-do-programmers-fail-to-write-good-unit-tests

In this blog post I wanted to examine an article I found about unit testing. I think that since unit tests were one of the first types of testing we learned about and we have used unit tests as a foundation for many other testing methods this semester, reviewing this article serves as a great retrospective (and provides another viewpoint) on the importance of unit testing and defining criteria on writing “good” unit tests.

In the article, the author defines the significance of unit tests in creating software. They then go on to define some various qualities that make for a “good” unit test. I agree with the listed points, but I think this article could benefit by providing a few examples of good unit tests and maybe a few bad ones for comparison, especially since this is an article about programmers not correctly writing unit tests. I also think the article could better define what these “units” that are being tested are, since this term is used frequently throughout the article. Additionally, I think the article should better define what specifically is being tested in these “units” besides just saying “examine and test each unit of code separately”. Again, this is where some examples would greatly help illustrate the author’s point. The article then goes to list many benefits of writing unit tests. It ends with an interesting (and great) point of how just having unit tests isn’t necessarily beneficial (and can even be detrimental) if they are poorly written.

Overall, I think that after learning about and using unit tests a lot this semester, that this article can serve as a good introduction to the topic, and it certainly reaffirms what I have learned about unit testing, but I also think it requires some revisions to be more helpful in demonstrating the points it makes, as I find it to be somewhat vague in the fundamental parts of presenting the main concept of unit testing. I think that having a well written article about this topic is especially important as this type of testing is used as the basis for many other types of testing we have learned about. I also think that this article could include this point of how unit testing is used in the larger contexts of other types of testing such as ensuring code coverage to further prove its importance.

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

Regression Testing

Article link: https://dzone.com/articles/what-is-regression-testing-and-why-is-it-important

Today I learned about regression testing from an excellent article on DZone and why it is an essential part of software testing. As the article explains, regression testing involves testing the whole software product to ensure that any changes to the code doesn’t break what was already working in the product or other parts of the software. The article then goes through a great example of how fixing a bug in one part of an example piece of software can unintentionally result in another (previously working) part of the system to stop working properly. The article demonstrates really well that this breakage can occur despite unit tests showing that the bug was fixed properly. This to me is an especially important point as it shows the value in using multiple methods of testing to ensure software is performing correctly. One criticism I do have of this article is that I wish they gave an example of how to implement regression (the article does include a link to a tool that performs regression testing) testing in an actual program (or in context of their previous example).

Although after reading this article, the concept of regression testing seems simple, I find it very important as both a software user and software developer. In my personal experience as a user I have seen everything from operating systems to video games release updates that caused features that worked fine previously to become buggy or stop working entirely. From the user perspective I know how frustrating this can be, so I am glad that I learned how to prevent this problem as a software developer. Regression testing is definitely something I now want to implement into my personal software projects. Now I need to look into the tools that can help do this.

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

Technical Review

The school semester is almost over and slowly everything is coming to a completion. This will be my last post for the Testing Class, Over the course of it I have learned quite a lot of valuable skills in the Computer Science field.

The last covered topic of the class was the Technical Review, maybe not as advanced as previous exercises this one let us practice probably one of the most important and widely used techniques, the Technical Review, or simply code review. Some info about that can be found here. This is a form of static white-box testing technique which is conducted to spot the defects early in the life cycle that cannot be detected by black box testing techniques. It should not be lead by a person who wrote the code, or at least one member of the review has to be a somebody not associated with the code.

This is a very good and very easy form of troubleshooting and detecting bugs early in the production, and it should be used as soon as possible after the implementation of the code .

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Testing with MOCKING

Having learned about mocking it was finally time to put it to test. We were given some code and exercises to work with and learn by practice, I love that by the way, POGIL is awesome. We were given a Mocking Framework called Mockito to use and it seems like it is a very useful tool for testing.
I am still a little bit confused about Mockito and its use (practical side) but that is fine, there is plenty of knowledge base right on their own website here. Yes their logo is a Mojito…. I have read few things and it helped me to better understand the framework, the website also has links to FAQ and blogs by the creators. I believe anybody will be able to work with Mockito after doing some reading and maybe some practice.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

First STUBS now others…

Last time I have learned abut Stubs in programming, this time I came to find out that there is more to it then I thought. For the Testing class we had to read this article by Martin Fowler and learn about apparently different kinds of Stubs, but Mocks are not Stubs…..

The article is a little bit lengthy but it is a good source of information if you want to, or have to learn more about testing, it also had a plenty of examples and explanations how the differences between stubs and mocks and dummies and fakes look like. When it comes down to it remembering these definitions from Fowler is the minimum of work:

  • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
  • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
  • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
  • Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
  • Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Stubs

When it comes to testing software I am definitely all for it but at the same time I am for it by doing it the “old school” way. Even at work this mentality stands, but recently the more I learn about testing the more I understand the need for it.

Having learned more about the subject of testing I feel like I can talk a little bit about it. Stubs is the part I been educated on recently and it is a bit confusing but that will probably go away with time and practice. Anyway Stubs. Those in programming are (according to Wikipedia): a piece of code used to stand in for some other programming functionality. A stub may be a temporary substitute for yet-to-be-developed code. I do know how to use those but until now I didn’t know what they are called and that is cool in its own way. Everybody knows how to use some fake code that is there just to run something for a time or to fool rest of the code into working. Now you know what to call it to. A STUB!!!

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.