It’s certainly been a while since my last post. I’ve been slacking way too hard, especially with break, but now it’s time to lock in and focus on my work. 

For this blog post, I’ll be talking about Test Driven Development, or TDD for short. TDD is a “software development practice that focuses on creating unit test cases before developing the actual code.” It attempts to avoid or solve the issues that arise in “traditional testing.” TDD, rather than testing one big system, tests small chunks of code at a time. It also “follows an iterative process, where small chunks of code are developed, tested, and refined until they pass all tests.” This allows for errors to be found, debugged, and fixed as early as possible in the development process (BrowserStack).

In Kent Beck’s blogpost, “Canon TDD,” he lists the steps to properly adhering to TDD:

1. Write a list of the test scenarios you want to cover
2. Turn exactly one item on the list into an actual, concrete, runnable test
3. Change the code to make the test (& all previous tests) pass (adding items to the list as you discover them)
4. Optionally refactor to improve the implementation design
5. Until the list is empty, go back to #2

Being introduced to a process that differs so much from the “norm” and is also quite efficient and thorough is both refreshing and exciting to learn about. When this topic was first introduced in class, I was very lost but I picked it up not long after; but then again, the example we followed was a very simple one. Once we moved onto a more advanced one to work on within our groups, I was lost again. I understand the concept of Test Driven Development but putting it into practice, at least for now, seems pretty hard. It also seems like a skill that is easy to pick up but hard to master as some tests can be more beneficial than others when it comes to coverage or time management. 

I feel as though there are little downsides to TDD and when it comes to those downsides, they mostly lie in the capability of the individual. Forgetting to run tests, writing too many tests, writing too much for a test, and writing tests that are impractical are just some of the issues that may arise when using this practice. 

Overall, Test Driven Development is a practice that individuals and teams may want to use to try something new or to test if it’s more effective than their current one. It‘s a very different approach to the development processes that I’m familiar with but that’s not always a bad thing; and in this case, TDD seems like a great practice.

Sources Used:

https://www.browserstack.com/guide/what-is-test-driven-development

https://tidyfirst.substack.com/p/canon-tdd

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I decided to discuss the article “Security Testing: Types, Tools, and Best Practices” by Oliver Moradov. I chose this article because it compliments the security testing topic in the syllabus. This article discusses the main goals of security testing and the key principles behind security testing, and several examples of security testing and testing tools. In this blog post I will be discussing the section on the main goals of security testing

The first section of this article discusses security testing. The article defines security testing as a series of tests determining if the software is vulnerable to cyber-attacks. “Security testing checks whether the software is vulnerable to cyber-attacks and tests the impact of malicious or unexpected inputs on its operations. Security testing provides evidence that systems and information are safe and reliable and that they do not accept unauthorized inputs.” The article also describes security testing as a non-functional form of testing, which means that security testing does not focus on the software’s functionality. Security testing fits more into the category of non-functionality testing, meaning that security testing tests whether or not the application is designed or configured correctly. “Security testing is a type of non-functional testing. Unlike functional testing, which focuses on whether the software’s functions are working properly (“what” the software does), non-functional testing focuses on whether the application is designed and configured correctly (“how” it does it). “

The main goals attributed to security testing mentioned in the article are: identify assets, identify threats and vulnerabilities, identify risk, and perform remediation. The article defines identify assets as: “things that need to be protected, such as software applications and computing infrastructure.” This is essentially what the name describes. It is about finding what needs to be protected. The article then defines identify threats and vulnerabilities as: “activities that can cause damage to an asset, or weaknesses in one or more assets that can be exploited by attackers.” Much like the prior goal mentioned, this one is also fairly self explanatory. It is about finding weaknesses within the software and possible threats that are present. The third main goal the article mentions, identify risk is defined as : “security testing aims to evaluate the risk that specific threats or vulnerabilities will cause a negative impact to the business. Risk is evaluated by identifying the severity of a threat or vulnerability, and the likelihood and impact of exploitation.” Unlike the prior main goals, which are more focused on finding specific instances of something, identify risk is about evaluating the risk being identified not finding it. The last main goal that the article discusses is perform remediation and it is defined as: “security testing is not just a passive evaluation of assets. It provides actionable guidance for remediating vulnerabilities discovered, and can verify that vulnerabilities were successfully fixed.” This main goal is also unique when compared to the prior goals because this goal is focused on finding a solution to a vulnerability.

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.

The blog “Test Driven Development: The Best Thing That Has Happened to Software Design” explains the benefits of using Test Driven Development  in software development. It describes the focus on writing tests before writing the code, it emphasizes on how this approach will enhance software design, increase code quality, and allow for easier maintainability. The post highlights Test Driven Development’s ability to shift focus towards desired software behavior. I chose this blog post due to its relevance to the recently covered topics in class as well as how it can apply in writing better code. Test Driven Development is a topic that we just covered in class and I found it very interesting to see its uses and benefits.. Additionally, I am using this style of code in my CS-497 class which allowed me to further get hands-on experience with how Test Driven Development works.

After reading the blog post, I agreed with many of the points raised by the author of the blog. I found the idea of writing the tests first as a foundation of code construction seems like a great idea as when you are writing code you know how you want it to work which is how you will write the tests to make it pass. Once you have the tests you can write the code that will allow the tests that you have already created to pass. The idea of problem-solving to make the tests pass rather than troubleshooting seems like an efficient way of coding. The author highlighted an aspect of Test Driven Development that I found very beneficial as it can highly increase efficiency is how creating the tests first gives you better insight on how your code is not working properly. If you are getting the wrong output making your test fail you will know how to fix it better than without having that test in place.

This blog post allowed me to consider different aspects of solutions for coding because different styles have different benefits while developing  software. In addition, it reinforced the importance of writing clean, concise code and underscored the significance of thorough testing which are also key aspects of this class.Moving forward, I would like to and plan to incorporate the style of Test Driven Development more into my coding practices. By focusing first on test creation and then writing the code to make the tests pass, I can aim to enhance the efficiency and quality of my code. In conclusion, I believe that using Test Driven Development will increase my workflow and coding skills that will be beneficial not only in this class but potentially for the rest of my career.

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

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Common Defects in Software Development

In the fast-paced world of software development, the creation of bug-free software remains a significant challenge. Despite advancements in technology and methodology, software defects or bugs continue to impede the smooth functioning of applications. Understanding the reasons behind these defects is crucial for developing more reliable and efficient software systems.

1. Human Error: A Prime Culprit

Human error remains one of the primary sources of software defects. This can range from simple typos in the code to more complex errors in logic or algorithm design. Programmers, regardless of their experience level, are susceptible to making mistakes, especially when working under pressure or tight deadlines. To mitigate this, implementing a robust review process, including peer reviews and pair programming, can help in identifying and rectifying errors early in the development cycle.

2. The Complexity Conundrum

As software systems grow in complexity, the likelihood of defects increases exponentially. Complex systems require a deep understanding and meticulous handling to ensure all parts work seamlessly together. Breaking down the software into smaller, more manageable modules can aid in reducing complexity and making the system more understandable and less prone to errors.

3. The Testing Trap

A common pitfall in software development is insufficient testing. Skipping comprehensive testing phases or having inadequate test coverage can lead to defects slipping into the production environment. Adopting a continuous testing approach and utilizing automated testing tools can help ensure thorough examination and identification of potential issues before deployment.

4. Documentation Dilemmas

Inadequate or outdated documentation can significantly contribute to software defects. Proper documentation ensures that developers have a clear understanding of the software’s design and functionality, facilitating easier debugging and maintenance. Investing time in maintaining detailed and up-to-date documentation can save considerable time and effort in the long run.

5. Tool Troubles

The choice and use of software development tools can also impact the quality of the final product. Using outdated or unsuitable tools can introduce bugs into the system. It is essential to select the right tools that align with the project’s needs and ensure they are correctly integrated and used effectively.

Prevention is Better than Cure

Addressing these common causes of software defects begins with acknowledging their presence and potential impact. By taking proactive steps such as enhancing the development process, enforcing coding standards, conducting regular code reviews, and ensuring comprehensive testing, developers can significantly reduce the occurrence of defects.

Furthermore, fostering a culture that values quality and attention to detail can encourage developers to take the necessary time and care to produce higher-quality code. Investing in training and continuous learning can also equip developers with the skills and knowledge needed to avoid common pitfalls.

The link to the blog I chose : https://www.devstringx.com/why-bugs-or-defects-in-your-software

From the blog CS@Worcester – Coding by asejdi and used with permission of the author. All other rights reserved by the author.

Dummies, Stubs, Spies, Fakes, and Mocks

Software testing is a crucial component of the software development lifecycle, ensuring that your application functions correctly and meets user expectations. One of the key concepts in unit testing is the use of test doubles, which help isolate the system under test (SUT) by replacing its dependencies. This isolation is essential for creating effective and reliable unit tests. In this blog, we will delve into the different types of test doubles: Dummy, Stub, Spy, Fake, and Mock, and explain their roles and usage with examples.

Dummy Objects

A Dummy object is the simplest form of a test double. Its sole purpose is to fill parameter lists without actually being used in the test itself. Typically, a Dummy can be a null object or an instance with no real logic, used just to satisfy method signature requirements. For instance, when testing a method that requires an interface which the test doesn’t interact with, you could pass a Dummy implementation of this interface. However, a Dummy should never affect the test outcome.

Example:

In this example, dummyBoard is a Dummy since the test does not interact with it beyond instantiation.

Fake Objects

Fakes are more sophisticated than Dummies. They have working implementations, but usually take shortcuts and are simplified versions of production code. Fakes are particularly useful when testing interactions with external resources, like databases. Instead of connecting to a real database, you can use a Fake object that simulates database operations.

Example:

Stubs

Stubs provide canned answers to calls made during the test, usually not responding to anything outside what’s programmed in for the test. They are used to supply the SUT with indirect input to test specific scenarios.

Example:

Mock Objects

Mocks are used to verify interactions between the SUT and its dependencies. They can assert that objects interact with each other in the right way, making them a powerful tool for behavior verification.

Example:

In this case, mock is used to ensure that the Module correctly logs messages when an exception is thrown.

Spy Objects

Spies are similar to Mocks but are used for recording information about how they were called. They can be used for more complex scenarios where you need to assert that certain methods were called a specific number of times or with certain parameters.

Example:

Here, spyLogger acts as a Spy, recording the number of times Log was called.

Understanding the differences between Dummies, Fakes, Stubs, Mocks, and Spies and when to use each can significantly enhance your unit testing strategy, leading to more maintainable and robust code. While these tools offer great flexibility, remember that the ultimate goal is to write clear, concise, and reliable unit tests that effectively cover your code’s functionality.

https://dipakgawade.medium.com/mocking-for-unit-tests-understand-the-concept-221b44f91cd

From the blog CS@Worcester – Coding by asejdi 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.