Testing code and software can come in many different forms, some may be better than others. In this post, we will look at path testing, or happy path testing. Path testing is representing your code in a linear graph, using nodes and arrows. The nodes represent lines of code, and the arrows dictate the flow of the code or program. It’s a fairly straightforward way of testing, depicting how you want your code to flow, and how the code actually flows. It can help you visualize the execution of your program.

In this blog post, it talks specifically about happy path testing, which is described as “a technique that tests the application through a positive flow to generate a default output,” or “a type of software testing that focuses on the most common and expected scenarios that a user will encounter when using an application.” Essentially, it allows you to see how your code executes in a typical environment. In the blog post, the example of an online shopping site is used, where the typical flow would be a user visiting the website and browsing through the products, adding some products to their cart and going to checkout, entering their shipping address and payment details, and finally finally receiving a confirmation and an email. That’s the happy path the website takes when a normal user goes to shop. This kind of testing ensured that nothing wrong occurred when it came to a normal execution. This is the same thing that happens when applying this testing strategy to your code, going through your code in a normal, typical situation and making sure you will not run into bugs and errors. Some steps to perform happy path testing effectively would be defining the scope and objectives of the testing, designing the test cases and scenarios, executing the test cases and scenarios, analyzing and reporting the results and outcomes, and fixing and retesting the issues and defects. The post also talks about the opposite of happy path testing, and some challenges when it comes to this kind of testing, such as overlooking negative and edge cases and relying on the happy path as a final verdict.

Although happy path testing is an effective testing strategy, it only covers the main part of your code, leaving some areas vulnerable to possible bugs and errors that may not be picked up or detected. But even with that, this is good for an initial testing strategy. It allows you to confirm that your code works as intended and expected when it comes to the most common scenarios of your code. Personally, I’m a fan of this kind of testing, being able to visualize the way my code works is nice. However, I know its limits and when it is effective and when it is not.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Once you learn to test your code, another thing you have to worry about is testing it as efficiently as possible. You can just write tests and hope that it ensures your code works effortlessly, but it may not always catch everything that can go wrong. Adopting some strategies and methods will be important in helping you determine how to go about testing your and managing that. 

There are a number of strategies that you can use and adapt. Early on in class, we went over some strategies very quickly that can be used or serve as a good base. Some of these consisted of black box and white box testing, dynamic and static testing, and some others. Each has their own way of testing, some can be better than others. Ultimately, it’s up to you to determine and figure out which one best suits you, the way you want to do things, and your code.

In this blog post, Janki Mehta writes about testing strategies, its key components, approaches, and some specific ones. They describe testing strategies as plans of “how software testing will be approached, executed, and managed throughout the software development life cycle.” They then describe the key components of the strategies, which are scope and overview, testing methodology, test environment specification, release control, risk analysis, testing tools, and review and approval. They dive into detail with the two approaches, proactive, where it focuses on detecting and catching bugs and defects before they even occur, and reactive, where it focuses on catching them afterwards. Some strategies they list were black box and white box testing, but some others too, like integration testing and regression testing, also describing what each of them are. At the end of the article, there are some final tips that can help easing the testing process and creating a comfortable environment when it comes to testing.

Knowing good strategies is important for testing code, and knowing multiple ones is even more important. It allows you to look around and figure out which fits best for your code and software, and adapt to it. Testing code can and probably will be difficult to get right all the time, learning all you can and having additional resources will be beneficial. I think that Mehta wrote a good article, it covers a lot of material, some of it can be seen as extra but it doesn’t hurt to know extra information, even if you can’t use it now. It’s clear the article is meant for a team to use as reference, but anyone can use it, not just a team. 

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Having your code and programs work is one thing, ensuring the code works effectively and efficiently is another. You can write good code, but it’s nothing if it does not work properly. When I tested my code, I would just run the whole thing to see if it worked, and with different inputs. When it didn’t work, I would strip it apart, run bits and pieces individually until I found the issue. Instead of meticulously scrolling through lines of code, you could use actual testing methods, like Junit testing

JUnit is a software testing framework for Java. Through the use of method calls, annotations, and assertions, you are able to create tests that will call methods and compare the output to the supposed output that you want. That way, you can create multiple tests for possible outputs your methods and program can have. 

In this blog post, Shinji Kanai writes everything they can about JUnit testing, what it is, how it works, the benefits, and how you can get started using JUnit. They say that JUnit can be used for unit testing, functional testing, and integration testing. They also say JUnit can be used for automation testing, to find errors in your code. They go on to show how to write test files, and how to write test code. They touch upon some other topics, like troubleshooting, assertions, debugging and exceptions, and other things. 

I chose this blog post as a good reference article, something to refer back to when you can’t remember what to do. At the same time, it’s also a really good beginner blog post for those who want to get into testing their code. I think Kanai did a good job encapsulating everything, not only summarizing the overall concept of JUnit testing, but at the same time going in depth about how to do things, and going over more topics for those who may find it helpful. Personally, I was unaware of the automation testing side of JUnit, and how it may be able to remove bugs before I even fix them, which is weird because typically you only catch errors and bugs when you run the code. 

Testing is one of the spots in coding where I knew I was lacking in. Before this, I never knew how to test my code effectively, but with this, I feel more confident in my abilities to write better code that will set me apart from others. As I continue along, I can picture myself as a better developer than I did when I first started university.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

When I first started coding in AP Computer Science, I found it fun. It was like solving a puzzle, a difficult one at first, but it slowly made sense. One thing I struggled with was clean code. I remember vaguely writing code that was disgustingly dirty, as in unorganized, unreadable to others, and all around messed up. I’m surprised I was able to get something to work in those conditions. I soon realized that clean code would be a game changer, as I would be able to read it clearly, and follow along easily.

Clean code consists of some points, having good and descriptive method and variable names, appropriate spacing between different lines of code, and good sectioning are some examples. Ultimately, these can go further based on context. Some variables may not need overly descriptive names if there’s enough context to imply what it is used for. 

In this blog post, Karolina Tóth interviews Robert C. Martin, or Uncle Bob, on his way of building quality code. The post is fairly lengthy but it has very good tips. Uncle Bob talks about what clean code is, its benefits, how not using clean code can negatively affect you, and many more. One tip he gives is keeping your functions as small as possible, because once they start to get large, the method starts to become confusing. By not writing clean code, you slow everything down. On a team, it’s difficult to work together if someone’s code looks like a 5 year old wrote it. By writing clean code, the team can work effectively and efficiently, ensuring quality code. 

I think this is a good post, Uncle Bob has good information, not only on clean code, but also boosting team morale and how to ease into using clean code. His knowledge in teamwork comes from his own experience and mistakes, which I like. Someone has to make mistakes for others to learn, and fortunately, Uncle Bob has done just that.

Clean code is important, whether you work in a team, or alone. It’s good practice to do so. When I first started, it was sloppy code. But now, I can’t stand seeing unorganized code. Even after we had learned clean code in class, I realized that mine wasn’t exactly perfect either. I liked my variable names to be descriptive, but short, and I made the short part priority because I’m lazy. But after reading this post, I understood that it’s not always good to keep them like that, having overly descriptive names can be beneficial, but when they have to be. I like things to be clean, and orderly, and neat, and whatnot, so I’ll be sure to refer back to this post, and the rest of Uncle Bob’s resources later down the line.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

When it comes to sharing your work publicly, there are certain things you have to do in order to protect it, and you. Whether the work is a form of art, product, or even code, you have to put a license on it. The creator can put software licenses on their code to allow users to use it in certain ways, according to the license agreement. 

Software licenses are categorized into types, which are ranked from least restrictive to most restrictive. The least is the public domain license, which has no restrictions on your code, meaning anyone can do anything with it. Next is the permissive license, similar to the public domain one, except it has some restrictions on how users can use, modify and redistribute the code. The next one is the copyleft license, which also has restrictions on how to use, modify and redistribute the code, but it also states users must distribute the source code with it. The most restrictive is the proprietary license, which only allows users to use the code if they agree to an agreement, and does not allow them to modify or redistribute the code. Under each of these types, there are licenses that have their own extra requirements, so it is important to look at each one to determine which is a good fit for your code.

In this blog post, Ibrahim Ogunbiyi gives us 7 practices that can help with license management. Step one is documenting your procurement process, document where you purchased software, who did it, when, and other important details. Having documentation on software purchases is important for when you need to look back for information. Step 2, having a central list of all software licenses. If there are multiple departments in your organization, having a central list containing all software licenses is good to have. Step 3, understanding all software license agreements, reading through and understanding the agreements. Step 4, implementing a software license management tool. Having a tool to manage your licenses, tracking use, and optimizing use is really nice to have. This can also knock out step 5, regularly tracking license use, and step 6, keeping licenses accurate and up to date. The tool can do that for you, but sometimes, doing it yourself is nice. Step 7 is training employees about license management, which is important for an organization. Having everyone follow the same methods of management promotes uniformity, which makes things easier.

Although I may not belong to an organization that purchases software, I feel knowing these steps is good. Software licenses, or licenses in general, are scary and confusing. It’s not something you are taught in school, so having learned it in class was nice. I can’t quite relate to this just yet, but it is important to know management tips so that when the time comes, I will be ready. In the future, I know I will be coming back to refresh my mind on it.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

When it comes to software, and working on it as a team, or sharing it with others, Git appears to be the bread and butter of it. That is what class is kind of centralized around, learning how to use Git, and how it benefits you and others. At first glance, it appears very hard. However, after understanding its role in the greater scheme of things and putting it into practice, it’s not all that hard. Originally, I thought Git was another coding language, like Java or C++. I was severely wrong, as it is more similarly to Bash in a way, but unique in its own way. It allows for people to create code, share it with others online, where it can be used, changed, and reshared with the original creator or other people, where the same thing can happen, making branches of versions of code different from the last.

To use Git, you need a code hosting platform, like GitHub or GitLab, and a code editor, like VS Code. You don’t need to use these specific sites or editors, as each is similar and unique in their own way. Once you have these, you can start writing your code, stage it, commit it and push it into your code hosting platform on the internet for others to see, use and change. Or you could fork some code you see and change it up however you want, stage, commit and push it back and see what others think. Git allows not only teams to work on code together, but strangers to work on it, from all over the world. 

But who says Git can only be used for coding purposes? In this blog post, by Bruno Brito, they describe how Git can be used for designers, as in those creating graphic design and photo editing. In the post, they describe what Git is, how it is used, how to use it, and other things needed to know as a beginner to Git. However, instead of editing code, they use photo editing software. In the specific post, they are using Tower, which is similar to our VS Code. They describe how to create repos, how to stage and commit, and then how to use code hosting platforms, or for designers, cloud-based hosting platforms, to maintain synchronization. Then they go on to describe forking, cloning, pushing, pulling and branches. 

At quick glance, this could be interpreted as a tutorial for Git, which it is. But it is in a setting different from coding, specifically for design. I like this post because it shows that Git can be used for other fields, similar to my last post. I find that these ways of organizing code, among teams and many people, efficiently, and it allows many people to chip in, and upload their work. Although the post to me is essentially useless, as I have already learned how to do Git, it can be helpful to others who are looking for ways to create an efficient work environment. I can relate to this in a way, as a communications student as well, I am somewhat fond of art, and graphic design. I may not use Git if I am creating work on my own. But in a team, keeping track of who is doing what, and what changes have been made to this piece and what not, it can be helpful.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

This week in class, we went over the process of Scrum. Essentially, it is a loose framework on how a team should be working if they want the greatest potential from that work. I say ‘loose’ because it is loose, other than providing how the process should go, it allows teams to not only follow this framework, but adapt it and make it unique for their team and their work. I like this methodology for this reason. 

Scrum states that a team consists of developers, a product owner and a scrum master. Each has their own roles and responsibilities in the process. The process has five parts. The main event is the Sprint, which is a one month process where everyone is working in order to achieve a goal. Before this can happen, there is the Sprint planning, which is planning the Sprint and figuring out what needs to be done. Everyday before people start working, there is the Daily Scrum, a short meeting about what needs to be done that day. At the end of the Sprint, there is the Sprint review, going over the results and progress of the Sprint, and the Sprint retrospective, reflecting on the Sprint, as a whole and on individual parts, so that the next Sprint is better. Each part, and the roles, are described in detail in the Scrum guide.

In this blog post, Gregory Crown and Robert Pieper talk about how Scrum could be used outside the realm of software development, like marketing. I chose this particular post because not only does it connect to what we’re learning in class, it talks about how Scrum can be used outside of software development. In the post, they specifically talk about how marketing can use the framework of Scrum, and how it benefits from it. Pieper says that if it is a complex activity or problem, Scrum can help. He describes complex as something requiring a lot of opinions. He uses a water bottle as an example, saying one stakeholder may not like the color, another may ask what the purpose of the rubber thing at the bottom of it is, etc. Essentially, if you show the benefits of something, and there are a lot of different opinions on it, you can benefit from Scrum. He describes it in a very nice way, saying, “if you’re in a subjective environment where you’re getting a lot of opinions, use Scrum.” He says that if what you’re working on is something that just meets requirements, and then moves on, you don’t need Scrum. 

Personally, I agree with what he says. On paper, Scrum is an excellent framework for a lot of things. It has the layout on how to do things, but allows people to fill in the rest, however necessary for things to be done. It is a clean way of doing things, strict yet flexible. This shouldn’t just be a computer science thing either, if others can benefit from this, do it.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.