With software development, working in teams is typically normal. Being able to work in a team is important. But what is also equally important is interacting with stakeholders. A team does not make a project just because, typically someone comes up to the team and gives an idea and the team gets to work. That is an extremely watered down version of how it happens, but that is how it works. This can be somewhat confusing so let’s break it down. 

In this blog post, they talk about what a stakeholder is, why they are important and then some examples of a stakeholder. The post defines a stakeholder as a group of people or groups affected by a software development project. They are in the best position to offer specific input on needs at their level. Essentially, they are people who know what they want for this project and those whose interests are important for the project. It is important to get their input on the project because they guide the project in a way. They are able to create a list of things that are needed for the project and a way for the developers to figure out what they are working on exactly. You do not want to ignore the advice of stakeholders and neglect them, as that means the developers are just making the wrong thing. But who is considered a stakeholder? End-users are good to consider, as they are the ones to be using it once it is complete. Knowing their input and how it affects them is important. People like managers, project managers, developers, and partners are all important, as they ensure that certain aspects of the project are doable. Certain authorities are also important to consider, such as shareholders or company owners. It is hard to get everyone in for a meeting on the project all at once, so getting representatives is a better alternative. Determining whether or not their input is needed is also important, as to not waste someone’s time. But again, how do you determine that? There are some questions you can ask, such as “who will be affected by this product,” “how will workflows change,” and “are there any people whose support is vital to the project.” 

Understanding who has valuable input and is able to shape the project will be key to you as a developer, as it lays the foundation and blueprint for what you and your team will be doing. It may be difficult to get everything everyone wants, and you may have to cut some things. But knowing when to do so is up to you and the 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.

A topic we touched upon in class for a tiny bit was mutation testing. It is a different kind of software testing, where it alters your code and then runs your tests. If your tests fail, that means your tests are good. If your tests pass, that means your tests are not good. The altered versions of the code are called mutants, and if they are caught by the tests, as in failed, they are considered killed. If they pass, they are considered to have survived. The concept is strange, but can be effective, especially in finding inaccurate tests or seeing if you have enough tests.

In this blog post, Uncle Bob talks about his experience with mutation testing, how he came upon it, some benefits and how it works. He starts off by stating some issues with unit testing, such as writing enough tests, covering every line, branch, or path, and whether or not a test will fail depending on if you change some code. He answers these issues with sufficiency, coverage, and semantic stability, all of which can be solved by using mutation testing. It is fairly simple to run, and there is multiple ways to go about it. You run pitest tool, which alters your code a little bit, such as inverting if statements. It will do this more than once, where each variation of your code is a mutant. Then, for each mutant, it will run through all of your tests. If the tests fail, the mutant is killed, and if the tests pass, the mutant survived. Ideally, you want all of the tests to fail, which may be difficult to wrap your head around, typically you want your tests to pass. Having mutation testing is just another layer of testing to ensure your code is working properly. If a mutant survived, a number of things could have happened, such as ignored tests or discipline became too relaxed and people started writing sloppy code. Either way, it’s a good way to reinforce your tests and code. 

We did not really get to play around with this a lot in class, but it was cool to see how it worked. It had created multiple batches of mutants and might have ran the tests individually, but I may be wrong about that. If we had the chance to run it on code that we wrote, or if I had ran it on code that I wrote, maybe I could have understood it more. I will definitely use this in the future.

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 working on a big project, in a big team, with a lot of other people working together, things can become confusing. Sometimes, code may not work, or you will not entirely understand what is happening. The best thing to do is step back and take a technical review. Review the code, the goals, and any other areas that may be in need of improvement or assistance. Take the time to straighten things out so you and the team can get back to work efficiently and effectively. But how do you go about a technical review?

In this blog post, Tony Karrer talks about what a technical review is, some ways to identify when you need to review, some strategies, and some areas of review. They describe a technical review as “a deep-dive assessment of your software, infrastructure, team and processes,” and that “it provides findings and recommendations intended to foster a mutual understanding between business and software leaders, shedding light on the current state of your technology and your team.” Some signs that you are in need of a technical review are slow or late delivery, random or persistent bugs, and sleepless nights from strategic worries. However, taking a technical review shouldn’t just be in response to malfunction, it can be due to scaling and new markets, keeping up with competition, outgrowing your stack, changes to the tech team, or simply because you want to be on top of things. Karrer describes four strategies, each different from the other, ranging from general to specific and in depth. They are straightforward analysis, pragmatic assessment, expert recommendations, and finding sessions. After determining which strategy you are comfortable with, you can go ahead and start reviewing. They provide some examples of where you may want to review, including background information to get a general idea of the project, architecture, targeted code, or process and team. If there are areas that need work or are struggling, then that is one hundred percent a spot you want to review. While you are doing that, create a summary and list your findings, and include some recommendations or solutions if you have any. Finally, bring them to the review meeting, where you will review the project together with your team and sort out the issues and find possible solutions.

Doing this in class was actually fairly helpful. I feel like if it was my code, I would have found more benefit in it, but I understand the premise of it, it’s good to have multiple people look at the code and come together and see what kind of issues we found. 

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 you go to write code, maybe you already know what you want the code to do, knowing what it should give you as outputs and answers, but you might not know how to go about writing the code itself. In test driven development, you start with writing the tests first, and then trying to pass those tests, slowly as you go. It sounds like a strange approach to it but it is not as bad as it sounds.

In this blog post, Arek Torczuk talks about test driven development, and how it is the best thing that can happen to software development. First, they start off by describing test driven development, where they say it is, simply, a failing phase, a passing phase, and then a refactoring phase. In the failing phase, we create a test that will fail. In the passing phase, we create or write code, minimal code, that will pass the test. In the refactoring phase, we clean up the tests. Typically with coding, you would write the code, and then write tests. However, Torczuk presents some problems with this way of code development, like when to stop writing tests, or when you are sure implementation is finished. With test driven development, they say there are benefits, such as when writing tests, it makes you ask yourself, what do you want the code to do. They say that you should know the answers to these tests before the code is written. They then go on to provide situations where code may be impossible to test, and how test driven development can be used to help that, like using mocking. They provide code examples with these too, to further help visualize solutions. They provide some additional sources at the end of the article in the event you would like to learn more about test driven development. 

This is a strange way to write code, and for those used to writing code before everything else, this can be a difficult adjustment. Personally, I found it fairly difficult to start, but afterwards I was able to write the tests, and then write the code to pass those tests, and then keep doing that. The tests do provide a build up of the code, instead of doing everything all at once, which was what Torczuk was trying to get at with his blog post. It allows the tests to provide the framework of the code and lay it out. 

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

Testing is an important part of coding, and software development. Sometimes though, testing can be tedious work, and creating tests that work properly according to your code can be difficult. This should be the case anyways, as testing is a key aspect to software development, but what if you could do this process a bit more quickly. Creating mocks and stubs can be a good alternative, especially if multiple people are working on different parts of the same project or software. 

In this blog post, June Jung touches upon mock and stub testing. They describe mock testing as “creating a fake version of an external or internal service that can stand in for the real one,” and stub testing as “creating a stand-in, but a stub only mocks the behavior, but not the entire object.” The whole idea of mocks and stubs is to create a fake or a stand-in that does not do anything. This may seem strange, having completely useless methods and functions, but the thing we want to test for is the interactions between the methods and functions. Seeing whether or not they return the correct return values, call the correct methods, etc. This will reduce the amount of time needed to test the functions, compared to testing full, complete functions and methods. Jung says that by using mocks and stubs, you can “reproduce more complex scenarios more easily. For instance, it is much easier to test the many error responses you might get from the filesystem than to actually create the condition.” Jung says this specifically for unit + component testing, but this principle can apply for any kind of testing. In fact, they touch upon multiple cases where mocks and stubs can be used, such as internal functions, integration testing, and contract-based testing. They also provide code examples, and graphs to help you visualize the concept, which can be helpful.

Jung says that as your code grows, your tests should as well, meaning you shouldn’t continue to use the same tests as you continue to write more code, losing the mocks and the stubs. That being said, they’re good to help start, providing a base to continue with. Jung’s blog post is a good resource, as they also have linked another post that goes into the difference between mocks and stubs. It also appears that their blog post is part of multiple posts, which may be worth looking at for more information.

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

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.