Based on this article by Denis Kranjcec: How I failed at Test-Driven Development and what it took to get it right

For the past couple weeks, Test-Driven Development has been the focus of our learning. We’ve done a small project in class creating a simple rover instruction program, which built our confidence and knowledge on how TDD works. Then, we used what we learned to individually create a unique word counter with string input. Since then, I have taken a slight liking to TDD, although it may just be a honeymoon phase. Well, my last blog post was about why Test Driven development is so good. This time, I sought out to find peoples’ personal failures with TDD, and why it failed. This is how I found How I failed at Test-Driven Development and what it took to get it right by Denis Kranjcec. 

Kranjcec begins his article by summarizing that he took a shot with TDD, and missed. But why did he miss? He dives into the reasons, and after a quick discussion on what TDD is and how it is supposed to improve code, he came to the conclusion that it wasn’t TDD’s fault, it was his. 

To start off, Kranjcec was using DDD (Domain-Driven Design), which led to his code being easy to comprehend, but his tests were more complex and difficult to maintain. After trying TDD again, he eventually realized that his biggest mistake was “starting with the simplest use cases and building up to the more complex ones” (Kranjcec). This seems to be a common problem with TDD users, as they tend to stick to more complicated tests than easier ones in exchange for fewer tests total. 

His solution was to change the way he wrote code and designed. This was done by breaking his work down into many smaller steps and lots of commits each day, in addition to refactoring his code. In short, he noticed his code was much simpler to understand and shorter, with other benefits as well.

I selected this article because after only seeing the benefits of TDD, I wanted to see the struggles people had with it. Although this article wasn’t about the faults of TDD, it shows the personal mishaps or mistakes that one can make when working with TDD, which can lead to a greater understanding of it in the end. 

I did like this article because it was an alternate perspective on how TDD can go. I learned to be patient with my code, and to try and stick with simpler tests and design in order to make TDD more effective. I think this article is a good reminder for self reflection on your own work, as it may not always be another’s fault if it doesn’t work. I hope to apply such knowledge in future projects using TDD, keeping in mind that simplicity is key.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Article: https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

Last class, we got some hands-on experience with using Test Driven Development. These concepts always feel more concrete and understandable when actually working with them  yourself, rather than only reading articles or looking at examples. I’ve since gotten the hang of this method of development, and wanted to look into how it compares with other development strategies. Such is how I found Test Driven Development is the best thing that has happened to software design by Arek Torczuk.

Throughout the entire article, Torczuk compares the methodologies of code-driven tests and test-driven code. In other words, he judges whether code-first test later is better than test-now code later, respectively. The results for this vary, of course; some companies or teams may benefit more from one strategy than the other. A noted flaw of code-driven testing is that your tests do not challenge the implementation and design of your code. You can create all the tests you’d like on a specific method, but nothing would make you second-guess the way you wrote the method. 

This is where the test-driven approach would come into play. Having already written the tests, you have a better idea of what your code should look like, and how it should act. As Torczuk states, you can ask yourself “What do I expect from the code?” with writing tests before the method (Torczuk). Essentially, with TDD, you know all the answers to your questions and when enough is enough in terms of tests & code. In my mind, it makes the process more streamlined.

Another important part of TDD Torczuk mentions is that it gives quick feedback about the design of your software. You’ll sooner realize the potential issues with your existing codebase, and how it might affect your ability to add new functionality. 

I selected this article because test-driven development piqued my interest after I had more time to experiment with it. This article grabbed my attention specifically because it didn’t just reiterate the concept of Test Driven Development over and over. Another quite useful part of this article is its inclusion of real examples of TDD by the author.

The content of this article was clear cut and organized, and even though it may not have been a ton of new information, it was a different perspective comparing test-driven development and code-driven tests. I learned that generally TDD is more effective at producing well-implemented code than simply writing the method first and tests later. Seeing as we are continuing to learn TDD, I’m confident that I’ll be able to use this in my future projects/jobs if necessary. Or, I could suggest it to my team if we are struggling with writing tests after code.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

In class, we began learning about the use of mocking in software testing. After doing an activity, I realized I only slightly understood the purpose of it. So, I decided to investigate, which is when I found The Art of Mocking by Gil Zilberfeld and Dror Helper.

The article begins by giving an introduction to unit tests for those who might not be familiar. They also give an example in C#, which is the language they use for the rest of the article. However, this does not impact information about mocking besides the syntax of the examples.

Once unit tests are covered, hand-rolled mock tests are introduced: they are classes that the developer(s) code which take the place of the real objects for testing purposes. It might not accurately test the system, but it ensures the business logic of the class works. 

The types of mocking listed are those manually made by the developers and those auto generated by mocking frameworks (Mockito or Moq). The article goes quite in depth into mocking frameworks, in their types, what they do, and what to look for when choosing one. Zilberfeld and Helper also discuss the benefits of mocking, which generally boils down to the fact that mocking cuts loose extra requirements for testing, such as databases and other external/complex resources.

Lastly, the best practices and potential hazards are listed. From what I gathered, the important ones were:

• Only use fake objects when necessary, as too many can create weak/fragile tests
• Understand what you’re testing and the dependency
• At most two assertions/verifications per test

I selected this article because I was struggling a little bit with what mocking was and why it was useful. I had somewhat understood the concept and the idea behind it in class, but needed to go on a deeper dive to get a better grip on it. This resource also seems pretty real, in the sense of it feels homemade and focused; all the important stuff is in the articles themselves, not a subscription or anything. 

This article is superb with its examples and clear, in-depth explanations of unit tests and mocking. The formatting is easy to follow and allows for smooth learning and transitions from concept to concept. I personally believe that mocking is quite useful when applied lightly. I learned that Verify should only be used in fake objects when it’s the only way your program can pass or fail; otherwise, it might not matter whether every method actually calls the expected method. 

This affected me in a positive way as it gave me greater insight to mocking and more confidence in my personal understanding as to why we use it. I expect to apply this in a future job when I might need to test a method that uses database information, but it would take too many resources to use the database for testing purposes.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

https://web.dev/articles/ta-test-cases

Last week, we tracked the path a program would take using program graphs. The program graph is good to represent the overall structure of a program; it shows all the ways the code can go. 

Afterwards, I wondered about the other types of paths a program could take, whether it be the best case, worst case, etc. That’s when I found Ramona Schwering’s article about test cases and happy paths.

Although I primarily read this article for it’s definitions and information on the different paths a software could provide, it also covers the idea of a test case and how to prioritize the right ones. Schwering first reminds us what a test case does whilst checking the results of the program: it verifies the program does what it’s intended to do, and it validates the program is what the customer or user wants. 

Next, Schwering explains what drew me to the article in the first place: test paths and their outcomes. The first path is known as the happy path, since it applies to the most common use case of your program; this is what should happen and what we want to happen. The second path is the scary path, which is used to catch errors and ugly outcomes. 

Schwering lists other test paths that aren’t used as frequently as the first two but could be important to recognize. I’ll talk about a few I find interesting.

• An angry path is supposed to get an error; making sure error handling works.

• A desolate path would be important for programs dealing with input data, as it tests to see if it’s given enough data to function correctly. 

Lastly, Schwering goes over the best practices for writing test cases, and how there are two patterns used to structure the cases: Arrange, act, assert and Given, when, then.

I selected this article because it covered my topic of interest and I also enjoyed Schwering’s straight to the point, easy to understand writing style. I decided to do a deeper dive on Schwering herself and found she’s a software developer and tester that speaks at international conferences worldwide. Reading through the post, I found the organization of the information to be helpful in my learning along with the information itself being reflective of my thoughts on our recent classes. 

The content Schwering provides in this article is great for a quick read for anyone wanting to learn more about testing. I personally believe the paths she went over are important to prioritize, especially happy and scary paths. I refreshed myself on the duties of a test case and learned multiple kinds of test paths, and how their importances varies from situation to situation. I enjoyed this article especially due to Schwering’s little illustrations and how easy it was to understand the paths. I hope to create test cases in the future with these paths in mind, using them to my advantage when possible.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

https://www.testbytes.net/blog/boundary-value-analysis

This past week we began understanding and practicing boundary value testing using simple programs and, of course, simple tests. This blog post discusses that same topic, and gives multiple real life-scenarios and dives deep into the subject. Although it is not a super difficult subject to grasp (in my opinion), I feel this is a good way to reinforce those ideas we learned in class.

This blog by testbytes gives all the information one would need to give them a solid starting ground for boundary value testing. It first explains the concept of the testing model and why it would be done, such as explaining how testers hope to identify errors more proficiently. An example is given, using discount percentages that apply ONLY when purchase totals reach a certain threshold. The lower boundary of the first discount is given, testing if the total is less than $10 (which should mean a 0% discount). Then, the upper boundary of the first discount is checked, with a $10 order receiving an expected 5% discount, so on and so forth. 

Later the blog discusses the different types of boundary value testing as well as their distinctions and the disadvantages and advantages of this type of testing. 

I selected this resource because it gives a quick definition of boundary value testing but then goes into further detail on the subject with good examples and explanations. It is a well thought out post that gave me a more concrete understanding of boundary value testing and edge cases. 

Testbytes on its own is a reliable source for this specific information since it is an entire company dedicated to software testing and quality assurance. Through checking out their other posts, I see they have a variety of testing area blogs including mobile apps, web apps, games, automation, security, and more. 

Overall, this resource is great to refer back to due to its consistent information and easy to understand descriptions. 

As previously mentioned, the content in this blog post by Testbytes is a really solid basis for a good understanding of boundary value testing. I can’t say that it is the highest quality and in-depth education on the subject one can receive, but it’s useful for someone like me who is just getting started. 

Personally, I really enjoyed the material, especially the example given at the start. Although I wasn’t struggling with what we were learning in class, there were times where I had a moment of confusion. This is a quick bit of information that instilled some more confidence in me about this topic. One main thing I learned through this blog is a big disadvantage of BVA is truly how many test cases it may require to check all boundaries/edges, which can lead to a lot of effort on the system and more power/time consumption. I expect to use such advantages and disadvantages when creating test cases for my future individual and work projects.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

link to blog at the end:

Have you ever heard a word or phrase that you feel like you should understand but you just don’t? It’s happened to many people, and I’m sure it is not uncommon in the software industry. Certain software terms are either confusing or unknown, which is perfectly understandable!

Chris Kenst’s blog post relates to what we studied in class this past week, as it correlates with and even mentions some of the terms we learned, such as black box testing. It will hopefully help the definitions we previously learned stick in my head as the weeks go by.

This blog post is all about lingo. It aims to better prepare students and software-testing newbies for the confusing jargon coming out of their coworkers’ mouths. It is in a simple glossary format, which is easy to understand and refer back to from time to time. There are 50 terms listed as well, so there may be some left out, but the ones listed are what you are most likely to hear in the workplace or in communication. Kenst also mentions at the end of the post that an increased mutual understanding of such terms can lead to increased productivity and collaboration.

I chose to cover this blog post because it is easy to get lost in all the mumbo jumbo tech buzzwords flying around the internet. It is like being a parent and learning what your kids’ slang means; except the kids are your coworkers and the slang is important keywords for your profession. I would not want to be the one guy at a meeting who does not understand “black-box testing” or what “domain testing” is. Jokes aside, this is a great resource for my fellow students to refer back to, especially as we are just beginning our software testing journey. These terms are important to know, because otherwise you might fall behind as new terms and testing variations are created. 

I personally believe this is a great starting point for those new to software testing (like me) and those who might need a refresher every now and then whenever their coworker says something unfamiliar. I learned how “high volume automated testing” involves auto generation, execution, and evaluation of multiple tests that may be weaker and not as thorough on their own, but together expose bugs and weaknesses. I will continue to learn more testing variations and other terms from this list to strengthen my confidence as a software tester and engineer. I hope to apply this knowledge in the future whether it be at a job interview or in a working environment, proving to my coworkers that I understand the language they are speaking and can keep up with their discussions.

Blog: 50 Software Testing Terms Defined – Chris Kenst

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Ever struggle to read another developer’s code? Code should be easy to follow along with, especially for a reader entirely new to the codebase. However, sometimes developers write “spaghetti code”, with random variables or methods mixed together in a non-understandable manner. 

Gary Espinosa of Reflectoring.io believes that clean code is the best code, and it’s super important for companies and coworkers. He lists suggestions such as variable names being descriptive, methods shortened, code broken up, etc. Let’s dive into what he suggests.

Espinosa discusses the huge importance of clean code, and how it can make or break a codebase. Not only is code the flesh and blood of a program, but it is also a form of communication between collaborating developers. It helps enable easy understanding of code and editability without errors. Companies who need to ensure their code is clean often spend time and resources just making it easy to comprehend.

Clean code should be readable; this involves grouping similar functions and classes together, similar variables, etc. The document should flow like an “engaging narrative from top to bottom” (Espinosa). If possible, one idea per line and one action per statement is key.

You should also be able to keep your code consistent. There must be a standard for writing code, variables, and methods. Examples of this would be using camelCase for all your variable and method names, using specific indentation rules, and more. A unifying language reduces differences.

One should strive for simplicity, but with descriptive language as well. Variables, methods, and classes should have meaningful names that describe the point of themselves easily. For example, you shouldn’t use a name like “x1” or “yY” as they don’t provide the reader any insight as to what they’re for.  

I selected this resource because it lines up with what we’re currently learning, and it is a key importance to being a software developer in the industry. If you want to have your pull requests approved, write clean, understandable code. This topic intrigued me because it’s quite simple but I wasn’t sure if there were any specific industry standards for clean code. There are definitely certain uniforms industry-wide, but I’m sure that it depends from company to company.

Espinosa’s article was informative, and explained what’s important and why about clean code. It’s useful to those new to programming, or those who are experienced in coding but just entering the professional industry.

I learned how important clean code actually is, not only to the programmer but to their coworkers and the company as a whole. Alongside this, the article taught me how to effectively organize and write code in a clean and understandable manner. This led to an increase in my confidence in my ability to clean up my code. I want to apply this knowledge to my future jobs and perhaps go back and clean up my old projects to make them easier to comprehend.

Article: https://reflectoring.io/clean-code/

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Introduction

I found an article by Ibrahim Ogunbiyi called Seven Best Practices for Managing Software Licenses. Just based on the title, it seemed to be what I was looking for. It starts off with the basics; what is software license management? According to Ogunbiyi, it’s simply “a document that provides guidelines for the use and distribution of software” (Ogunbiyi). It assists with the controlling, auditing, tracking, and management of a software in an organization and ensures that users comply with the regulations set in place.

Importance

The article discusses the importance of licenses. The reasons include but aren’t limited to:

• Legal compliance with regulations set by organizations/manufacturers
• Keeps track of software due dates; leads to productivity
• Helps manage/reduce costs through enhanced planning
• Optimizes software usage through usage and license tracking data
• Ensures only the use of authorized and secure software, avoiding malware or malicious attacks/breaches

At this point, I think many of those new to software licensing have already taken a huge step forward in their knowledge of the subject. It’s easy to dismiss licensing as something that only grand organizations deal with, but it can be necessary for any small business or individual who wants to protect their work. 

Best Practices

Finally, we reach the best practices as given by Ogunbiyi. In no particular order, these practices are: 

1. Documenting the process of obtaining the software
   1. Who, where, when, how it was purchased
   2. When it is due for renewal
   3. Keep documentation up to date and to certain standards
2. Centralize your list of software licenses
   1. This practice is good for organizations with multiple departments that each have separate licenses
3. Understand the agreements for your software license(s)
   1. Read terms and conditions
4. Use a software license management tool
   1. Assists in tracking, optimizing, and managing software licenses
5. Track license usage regularly
   1. Ensures compliance with rules and regulations
6. Make sure your software license(s) are up to date
   1. Keeps them tracked
   2. Prevents them from expiring
7. Teach employees about managing software licenses
   1. Ensures correct usage of software
   2. Keeps them knowledgeable about the license process and its guidelines

Why This Topic?

I chose this topic because it’s very underappreciated and not mentioned enough in the software development community (from my experience). This could also be useful for an organization or small team that is new to software development.

Conclusion

For me, this article was quite beneficial to my learning. Personally, I previously didn’t know anything about software licensing and the entire process about it. I won’t claim to be an expert on it now, but this article has helped me become a novice in understanding the subject. Although this article didn’t recommend specific licenses, it did teach me the process I should go about when acquiring or dealing with a license. In the future, when I am working on a project either individually or with a team, I’ll be more familiar with the guidelines and process around licensing, and can help my colleagues if they are unfamiliar.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

article link at the end

Overview

This week we began learning about different types of software methodologies, mainly focusing on SCRUM. Scrum, being one of the most popular software development organizational processes, has many factors to consider and to improve on. One of these pieces is the Scrum Meeting, a 15 minute or so meeting with your co-workers and “boss(es)” discussing the day’s work. However, such meetings can easily devolve or change into different forms; certain groups function differently. For example, one team of developers may find it beneficial to have shorter 5-10 minute meetings where there is less communication from each member. Another team may prefer longer meetings with each developer participating in a detailed discussion. But what should it really be about? How should people really be involved? This is where Mike Cohn’s article Daily Scrums: Synchronization Meetings, Not Status Meetings comes in.

What Not To Do

Cohn, a specialist in agile processes and helping companies utilize teams effectively, believes that many companies do Scrum meetings incorrectly. Most current scrum meetings involve each developer giving a report to their scrum master, whilst the other developers sit and wait their turn. Instead, he states that “the daily scrum meeting is designed for team members to synchronize their effort” (Cohn). This opposes the idea of such meetings being used to simply share what one is working on, and move on for the day.

Cohn’s Beliefs

Cohn believes that daily scrum meetings should have members enthusiastic about the project they’re working on with their team along with the progress being made. Such developers should also be sharing their progress and thoughts not only with the scrum master, but with the rest of the team as well. This encourages a broader discussion with more voices and teamwork involved. 

Cohn encourages Scrum Masters to participate in daily meetings, as they can then hear about impediments while also showing support for their team. Lastly, Scrum meetings should have brief updates that focus on what has been accomplished rather than what one spent time on.

Thoughts

I chose this article because it gives a truer, more refined approach to Scrum compared to the ones mentioned. Since I am a beginner to the idea and process of Scrum, I did not know of some of the problems with current iterations of daily scrum meetings. 

This article has been very helpful to me as it introduces what daily scrum meetings should be like. In the past, I had a misunderstanding about how Scrum meetings went; which lined up with what Cohn advised not to do. Although I have not had any real-life experience with Scrum meetings, I feel better prepared as for what to expect in future jobs. I will most likely be using this newfound knowledge in future projects, whether internship or job, big or small. I understand now that it’s best to look forward to scrum meetings as a time to come together and share, and to leave with excitement about progress.

Article: Daily Scrums: Synchronization Meetings, Not Status Meetings

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.