For this week’s blog post, I chose the article “Code Review Best Practices – Lessons from the Trenches” by Drazen Zaric. I chose this article because its topic fits perfectly with the cove review segment in the syllabus. This article discusses why you should do code reviews, how code reviews act as quality assurance, how code reviews function as a team improvement tool, how to prepare a pull request for preview, and, of course, how to review code. In this article, I will be discussing why you should do code reviews and how they work as quality assurance.

Reviewing code is one of the most essential parts of the development process. “It should be obvious that the primary purpose of code review is to assess the quality of the changes being introduced. I mean, the dictionary definition of review says precisely that ‘review (noun) – a formal assessment of something with the intention of instituting change if necessary.’ Of course, code being code, there’s a lot of things that can be checked and tested automatically, so there’s nuance to what needs to be checked in an actual code review.” As mentioned in the article, there are many things that can be tested and should be tested. This leads to a need for many people to review your code, and you will need to review many other people’s code to make sure the best possible software is being developed. Quality assurance must be done well as a significant part of making sure your software is the best it can be.

In this section of the blog post, I will discuss how the article mentions how code review is incredibly useful in quality assurance. “There are many ways in which code reviews help maintain the quality bar for the codebase and the product. In the end, it comes down to catching mistakes at a level that can hardly be automatically tested, such as architectural inconsistencies. Also, the code for automated tests should be reviewed, so there’s a meta-level at which reviews help with QA.” As mentioned, code review’s main boon to quality assurance is finding issues that can’t, or often need to be caught, through traditional testing methods, like automated testing. The article also mentions using checklists for storing what needs to be checked and how and what the results of said checks should be. “You can have your own checklist or make it a shared list for the team or a project. There’s a ton of material written on the usefulness of checklists. In Getting Things Done, David Allen puts forward a simple idea – our minds are great at processing information but terrible at storing and recalling it. That’s why checklists are a great way of externally storing and breaking down a planned or repetitive task.” Having a method of keeping track of what is done, what needs to be done, and what is incomplete is essential in working on any large project, let alone on a software development project.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the “Long Road” pattern discussed in chapter 3 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I often worry about not being able to learn or grow more in my field, becoming stagnant because there is nothing else I can learn. Thankfully, this pattern dissuaded those fears of mine and inspired great confidence in my future endeavors.

The quote that this pattern opens with immediately puts much of my concerns about the limits of what I would be able to learn to rest. “‘How long will it take to master aikido?’ a prospective student asks. ‘How long do you expect to live?’ is the only respectable response.” In comparing computer science to Aikido, it implies that no one can possibly learn all that there is to know in computer science. Another quote from this section that makes me even more excited to be a part of this field mentions that for every step you make, the finish line is two steps further away. “For every step you take toward mastery, your destination moves two steps further away. Embrace mastery as a lifelong endeavor. Learn to love the journey.” While this may seem like a disappointing aspect of our field for many, the limitless opportunity for me to grow is why I love this field of knowledge.

I did not think it was possible, but further reading in this section made me even more excited and proud to be in computer science. “Close your eyes and imagine the strangest possible role you could be playing in 10 years’ time. Have fun thinking of the wackiest possible future for yourself. Then think about 20, 30, and 40 years from now. What kinds of experiences do you want to have tried? Imagine that 40 years from now, you are asked to write a short description of your professional history and the biggest influences on your path. Use the output from that thought experiment to help you plan your future career choices.” This quote had me thinking about incredible and outlandish possibilities in this field, which made me even more eager and excited to be in this field than I thought possible.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I chose the article “Behavior Testing | What it is, Why & How to Automate?” from testsigma.com. I selected this article because it fits within the Behavioral testing section in the course topics section of the syllabus. This article goes into great detail about behavioral testing, from discussing what it is to explain how AI could be used in its implementation. For this blog post, however, I will discuss the sections on what behavioral testing is and a couple of methods that can be used to catch errors with behavioral testing.

The article describes behavioral testing as a form of functional testing designed to test the external functionality of a system. “Behavior testing or behavioral testing is a type of testing that focuses on testing the external behavior of a software application. It is a type of functional testing. It helps ensure that software systems meet the expectations and requirements of end-users, making it a valuable part of the software development and testing process. Behavior testing is also known as black-box testing.” As described by the article, behavioral testing is essential to ensure that the systems or products you are designing work well enough so your customers can use them efficiently. There are many different methods when using behavioral testing to find errors, such as equivalence partitioning.

According to the article, one method that can be used with behavioral testing that is good at finding errors is Equivalence Partitioning. “The equivalence partitioning testing technique involves dividing the input data into different classes or partitions, such as valid and invalid data, assuming the system will behave the same for both inputs. Example – For a login form, if the password requires at least eight characters, you might test one case with a 6-character password (invalid) and another with a 10-character password (valid).” When using equivalence partitioning, because you are dividing inputs into separate groups, in a way, you can do two things at once. One is that the system functions as it should with valid inputs, and the other can catch invalid inputs. Another way behavioral testing can be implemented is through boundary value analysis.

According to the article, boundary value analysis is a form of behavioral testing focusing on the possible range of inputs, specifically numerical inputs. “It focuses on testing the boundaries of input ranges, as errors often occur at the edges of these ranges. Test cases are designed for values at the lower and upper boundaries and just above and below. Example – If an input field accepts values from 1 to 100, the test data can be 0, 1, 2, 99, 100, and 101.” This kind of testing can be very helpful in making sure that you have accounted for the possible range of inputs that a user may enter, both valid and invalid.

Article: https://testsigma.com/guides/behavior-testing/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I covered the design pattern “Sustainable Motivations” from chapter three of “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. I chose “Sustainable Motivations” for this week’s pattern because I think that maintaining your motivations for your career is one of the most important things you can do for your mental health regarding software development. This chapter discusses why sustainable motivations are essential.

A section of this chapter that stuck with me was when the author says that there will be days when you are surprised that you are paid to write software and how happy you are with what you are working on. The author then mentions that those days are few and far between. “There will be days, weeks, and months when you love your job. You’ll chuckle to yourself, in awe that you actually get paid to develop software. The software you write will flow effortlessly from your mind through your fingertips, beautiful to behold in function and design. These are good and extraordinary days. In other words, they are not your ordinary days.” This was not a massive revelation for me, and I am well aware that most of my time working will be just that, working. I am not necessarily working somewhere because I love what I am developing, though I hope I do love what I am working on. That is the goal, after all.

The authors also go into some detail about what challenges a developer would face in the field. “As Paul Graham so rightly says, the typical programming job will put you face-to-face with tedious, vaguely defined, and needlessly complex problems. Nasty, wicked problems. What’s more, you may also be faced with bureaucracy, difficult personalities, and spotty leadership. There will be days, weeks, and months when you question your commitment to the craft. When you are confronted with such problems, it is crucial that your motivations to program are aligned with walking The Long Road.” Thankfully, with my experiences so far through my education, I feel prepared for the challenges that come from the work itself. From living life, I think that I can navigate bureaucratic and interpersonal issues reasonably well.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I have chosen to discuss the blog “An Overview of Unit Testing” by Kayode Adeniyi; this article discusses the importance of unit testing, what it is, the stages of the unit testing process, as well as discusses some differences between automated and manual unit testing. I chose this topic for this week’s blog post because unit testing fits well within the issues we are discussing in this class; I also like how the author discusses the differences between manual and automatic testing.

The first topic the blog discusses is what unit testing is. “Unit testing is a testing method in software development where each individual part (unit) of an application is tested to analyze its proper working. This approach is pretty common and used by most development teams to verify the accuracy of each software component.” In my opinion, understanding what unit testing is is imperative, especially understanding that each test tests a part of a system, not the whole system.

The blog then mentions some key aspects of unit testing, which are, in part, why they are so helpful for developers in all fields of software development. The key aspects mentioned are debugging errors from the root, having reliable testing procedures, repeatability at every stage, and simplicity over complexity. The article also mentions that separating each part of a program makes it much easier to find and correct errors that appear as you are working on a project. The blog also discusses the steps in developing unit tests.

The first step of the test development process is planning the test. The blog describes this first step as “… [T]he developer defines the objective and scope of the testing. Once the unit of application is identified, the developer also defines the criteria for testing it. Critical thinking and effective planning is needed at this stage to ensure focused testing.” Due to this step’s importance in determining the functionality of the final test, it is one of the most essential parts of the test development process.

The next phase of creating unit tests is the creation of test cases. The blog describes test cases as scenarios where the units’ functionality is being tested. The blog also discusses edge cases or scenarios in which an unlikely event is to occur but still needs to be tested in the event where this unlikely event happens. The article defines an edge case as “… an occurrence of an extreme scenario during the normal expected working of any software. They are often the rare events that can happen when a user uses the software application.” While these events are unlikely to occur, if your project will be used by many people over a long enough period of time, these edge cases are an inevitability.

Blog: https://blog.logrocket.com/product-management/unit-testing-guide/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the “Nurture Your Passion” pattern discussed in chapter 3 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I often worry about losing my passion for software development. This pattern discussed in the book has helped a lot with this particular anxiety.

The first part of this pattern mentions some everyday work environment issues that can break down your passion for your work. “You might be faced with demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues.” While I have worried about the inevitability of dealing with corporate hierarchies and toxic coworkers, I haven’t considered a work environment called a “project death march.” This initial part of the section did not alleviate my anxieties. However, as this section continues, my concerns are inflamed and relieved.

The authors described project death marches as the most damaging of the hostile conditions mentioned, and as they go into detail as to what a project death march entails, I agree with them. “It saps your time and energy, preventing you from taking any significant actions to protect your passion as more important issues like personal health and strained relations at home demand your attention.” This isn’t very good, mainly because it affects your passion, health, and relationships with your loved ones. Thankfully, the authors mention some ways to mitigate the harm done by this and other toxic traits a work environment may suffer from.

One of these examples is setting boundaries for what you are willing to put up with in a work environment. “This might mean you leave work while the rest of the team stays late, that you walk out of a meeting that has become abusive, steer a cynical conversation toward constructive topics, or refuse to distribute code that doesn’t meet your minimum standards.” While I certainly don’t have the confidence to stand up and leave a meeting or not stay late with my coworkers, I feel that I can steer conversations to a more positive topic and only distribute code that meets my standards. Reading this section also made me realize that I need to work on my confidence in standing up for myself and not be afraid to take a break and come back to something with fresh eyes.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will discuss the article “The Different Types of Software Testing” by Sten Pittet. This article discusses different kinds of tests, some differences between manual and automatic testing, and how to automate testing. I chose this article because it fits well with the software testing section of the syllabus. I also liked how the author went into great detail about the tests mentioned in the article. In this blog post, I will discuss some of the software testing methods in the article.

The first test discussed in the article is the unit test. “Unit tests are very low level and close to the source of an application. They consist in testing individual methods and functions of the classes, components, or modules used by your software. Unit tests are generally quite cheap to automate and can run very quickly by a continuous integration server.” From what is mentioned in the article, unit tests appear to be immensely helpful in testing smaller pieces of a program. Due to their ease of automation, they could also be beneficial for parts of a program that occur often. The following tests discussed in the article are integration tests.

Integration tests are imperative to ensure different parts of your program function well together. “Integration tests verify that different modules or services used by your application work well together. For example, it can be testing the interaction with the database or making sure that microservices work together as expected. These types of tests are more expensive to run as they require multiple parts of the application to be up and running.” While these tests are very helpful, due to requiring multiple systems to be running simultaneously, this type of test can be very costly to run regularly. The next test that I will discuss is the functional test.

Functional tests are very different from the prior two tests I have discussed, wherein the first two tests check the functionality of sections of your project. In contrast, available tests explicitly check for the project’s output. “Functional tests focus on the business requirements of an application. They only verify the output of an action and do not check the intermediate states of the system when performing that action.” This test is beneficial for the business application of a project. In contrast, the project’s pieces must function for the customer, and the project as a whole must also do what it was designed to do, and functional tests are great for determining this.

Article: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I chose to discuss the design principle of encapsulating what varies, as described in the article “Encapsulate What Varies (EWV)- Design Principle” by Pankaj. This article discusses the rationale behind encapsulating what varies, its two aspects, its benefits, the strategies of implementing encapsulating what varies, and gives an example of what encapsulating what varies looks like. This article falls in line with the design principle section of the syllabus and its sub-section encapsulating what varies. I also enjoyed the section discussing the benefits of encapsulating what varies. In this blog post, I will review a few of the benefits of encapsulating what varies are mentioned in the article.

The first benefit mentioned in the article that I will be discussing is flexibility. “Flexibility: By encapsulating the parts of the system that are subject to change, we make it easier to modify or replace those parts without affecting the rest of the system. This makes the system more flexible and easier to adapt to changing requirements.” As stated in the article, when encapsulating what varies, your resulting project becomes significantly more straightforward to maintain and update in the future. Instead of having to adjust one extensive method or class, possibly causing conflicts with other parts of the project, if you isolate the factors that are likely to change in the future, you prevent possible issues with updates causing problems with unrelated systems.

The next benefit that I will be discussing that comes with encapsulating what varies is reusability. “Reusability: By creating abstractions that represent the parts of the system that are subject to change, we make it possible to reuse those abstractions in different contexts. This can save time and effort when developing new features or applications.” Being able to reuse aspects of your code in other areas is very useful in reducing time developing and bug testing. Instead of making more methods or classes that could conflict with preexisting ones, you are reusing methods or classes that you already know will not conflict with other areas in your project.

Finally, I will discuss one of the greatest benefits that come with encapsulating what varies: maintainability. “Maintainability: By isolating the impact of changes to a specific part of the system, we make it easier to maintain the system over time. This reduces the risk of introducing unintended side effects or breaking existing functionality.” As I have also mentioned earlier in this blog post, isolating frequently changing parts of the project makes it much easier to diagnose bugs or other issues that may come up as the project is developed or as it is updated as time goes on.

Article: https://www.neatcode.org/encapsulate-what-varies/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.