Static vs Dynamic Testing

Testing software and ensuring it works as intended is a crucial part of software development. Two approaches to testing are static and dynamic. Static testing involves testing the software without running the code, while dynamic executes the program and tests its behavior in various situations.

Static Testing

The term static testing comes from examining the code in a “static” state rather than actually running it. Because the code is never actually executed with static testing, the focus of testing is on analyzing the software’s documentation along with the design of the code, and the code itself. Static testing is most beneficial in the early stages of development. Since the code is never being executed, a fully working implementation is not required unlike dynamic testing. Issues identified early in development are easier and less costly to fix resulting in better maintainability, and decreased time and money spent in the long term. Some static testing techniques include informal reviews, walkthroughs, static code reviews, and more.

Dynamic Testing

Dynamic testing involves actually executing the software and testing its behavior based on various inputs. Test cases are created to conduct test runs to identify defects and ensure the software meets the required specifications. Along with testing the software with various inputs and comparing to the expected outputs, error conditions are also tested. Error conditions are inputs that are outside of the valid input range, and the software should be able to handle the invalid input without any unexpected behavior. Dynamic testing is performed after coding and development are complete, whereas static testing usually begins in the early stages of development. Because dynamic testing executes the code, the software must be far enough in development where the software functions, performs, and secure as intended. Those reasons are why dynamic testing is to be completed after development. Some dynamic testing techniques include unit testing, integration testing, and system testing.

Conclusion

This article was chosen because it clearly explained what static and dynamic testing are and the differences between them. The article was also easy to follow along. I enjoyed learning about when static and dynamic testing are most beneficial because I was unaware that static testing begins in the earlier stages of development while dynamic is performed after development. So far in my software development journey, I have not written many tests for the code I have written, and have mainly done manual testing which takes extra time and may have errors. Gaining insight in these techniques will be helpful when testing code in the future.

Resource:

https://www.guru99.com/static-dynamic-testing.html

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

In the world of software development, ensuring that your application works as intended is crucial. This is where testing comes into play, serving as a safeguard against unexpected behavior and bugs. But how do you test effectively? This is where concepts like mocking, stubbing, and contract testing become vital. Let’s dive into these techniques and see how they can enhance your testing strategy.

• The Essence of Mocking and Stubbing

Mocking and stubbing are techniques used primarily in unit and component tests, but their usefulness extends beyond these. They are about creating fake versions of external or internal services to streamline and stabilize testing processes.

Mocking refers to creating a faux version of an external or internal service to replace the real one during testing. This is especially useful when your code interacts with object properties rather than behaviors. By mocking dependencies, you enable your tests to run more quickly and reliably since they are not bogged down by real-time data fetching or complex logic processing.

On the other hand, stubbing involves creating a stand-in for certain behaviors of an object rather than the entire object. This technique is useful when your implementation interacts only with specific behaviors of an object, enabling faster and more focused tests.

• Practical Applications

When your code uses external dependencies, such as system calls or database access, mocking or stubbing comes in handy. For example, instead of actually creating or deleting a file during a test, you can mock or stub the file system’s responses. This not only speeds up the testing process but also ensures that your tests remain independent and easy to manage.

• Contract Testing in Microservices

In a micro-services architecture, services interact based on predefined “contracts” detailing expected requests and responses. Contract testing verifies that these interactions meet the agreed-upon standards. Unlike traditional integration testing, contract testing focuses on the interfaces between services, making it a leaner and more targeted approach.

This type of testing is beneficial for checking the integrity and reliability of service interactions without deploying an entire system. It’s particularly effective in continuous integration pipelines, as it ensures that changes in one service don’t break the contract with another.

• The Role of Mocks and Stubs

In contract testing, mocks and stubs play a crucial role. By simulating the services that an application interacts with, developers can check the consistency and reliability of the application’s responses without relying on live services. This approach significantly reduces testing time and increases reliability.

• Conclusion

Testing is an integral part of the software development lifecycle, and techniques like mocking, stubbing, and contract testing are essential tools in a developer’s arsenal. By understanding and implementing these strategies, we can ensure that your tests are both efficient and effective, leading to more reliable and maintainable software.

The link to the initial blog post: https://circleci.com/blog/how-to-test-software-part-i-mocking-stubbing-and-contract-testing/

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

Concrete Skills

For this post, I read about the Concrete Skills pattern. This pattern is about when seeking a new role on a development team, the team may not want to risk the possibility that one may you be able to contribute to the team. They may think this because you may not have much concrete work to show your skillset and prove to teams you are able to contribute. The solution to this problem according to the text, is to acquire and maintain concrete skills. In order to do this, the text suggests collecting CVs of people whose skills you respect. Collecting CVs helps give an idea to what skills are useful and looked for when joining these teams. After learning these skills, then build a project using them to demonstrate that you can apply those newly learned skills.

I found this pattern to be useful because I am currently in the process of applying to jobs, so this pattern is very prevalent to me. Collecting CVs of those already in the industry, or those with more experience is something I had not thought of. However I believe it is a good way to find skills that you may be missing. Collecting a list of skills is also useful in the sense that common buzzwords used among CVs can be noted to help get past HR filters and managers who construct teams based off of those buzzwords.

I found the statement that describes hiring managers requiring to take a leap of faith on choosing who they hire, and having concrete work allows you to meet them halfway to be interesting. I found this to be interesting because it changes my perspective on the hiring process.

This pattern has changed the way I go about looking for new skills to learn. When learning new skills, I sometimes plateau and get overwhelmed with what I should be looking into. Now after reading this pattern, going into the future I will start collecting CVs because having a list of skills will be useful to direct my focus in the skills I should be learning.

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

The pattern being examined is “Learn How to Fail” and it emphasizes the inevitability of failure in everyone’s life. It also suggests that failure is not a sign of incompetence but rather an opportunity for growth and self-awareness. This encourages individuals to analyze their failures, understand the underlying patterns, and address them effectively without dwelling on past mistakes or striving for perfection.

This pattern resonates deeply with me due to the universal nature of failure and brings light to the fact it is a natural part of the learning process. I am one that values continuous self-improvement and find the idea of embracing failure as a catalyst for personal growth both empowering and liberating. Instead of viewing failure as inadequate, it is seen as an invaluable source of feedback that can inform my future decisions and actions.

One of the more interesting and useful aspects of this pattern is its emphasis on self-reflection and self-awareness. The pattern provides a practical framework for introspection and self-discovery by encouraging individuals to identify recurring patterns, habits, and behaviors that contribute to their failures. This will help individuals to make more informed choices and develop strategies to lessen their weaknesses effectively.

This pattern has certainly influenced the way I think about my intended profession and how I approach my work. Failure is now viewed as an opportunity for learning and development rather than a setback or source of shame. I intend to face challenges and setbacks during my career path and handle them with resilience, knowing that they will contribute to my overall growth and success.

While I do not disagree with the general message of this pattern, there can be cause for concern given how you might handle failure. It is important to acknowledge and learn from failure, it is just as important to celebrate successes and achievements. Failure can provide valuable lessons but can also overshadow or diminish one’s accomplishments in the search of self-improvement. Balancing both self-reflection and self-affirmation is crucial for maintaining a healthy mindset and sustained motivation.

In conclusion, the pattern underscores the importance of embracing failure as a steppingstone to personal and professional growth. By cultivating self-awareness, learning from mistakes, and approaching challenges with resilience, individuals can navigate their professional journeys with confidence and adaptability.

5. Perpetual Learning | Apprenticeship Patterns (oreilly.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

I hear this a lot: getting into tech, and specifically software engineering, because of money. It certainly seems to be the case that many people since maybe the 2010s have worked on Computer Science degrees solely because of the income and luxury of it, rather than an actual enjoyment of it.

I always found myself good with technology. When I took my first Computer Science course in high school, I always ended up completing assignments in 10-15 minutes when the allotted time was around two class periods. This is what I’m good at, as far as I can tell, but that’s not necessarily enough for me to make a career off of. If I don’t care about it, then I’m stagnating. If my motivation is simply that I’m good at it, it doesn’t necessarily inspire growth.

These are two examples of unsustainable motivations. The idea is that we can get trapped in the motivations we set up for what we do, and they lock us into a (most of the time, negative) mindset. Instead of enjoying my day to day work, I’ll see it as just work, and want the day to be over as soon as it starts, without actually growing as a person or in my skill level.

While the solution given tries to offer a practical approach (writing down your motivations and how much they factor in to your decision to stay a software developer), I don’t necessarily think this is a strong solution. I’m inclined to say that you have to have a more inquisitive investigation to why you care about this career, and what is really motivating you. Ultimately, you yourself create this motivation, it’s not out there waiting to be found. You can either construct for yourself an enjoyment of the journey, or you can only care about the outcomes.

From this, I would say solely caring about outcomes is unhealthy, and that mindset lends itself to motivations like reputation and money. As such, you have to ultimately figure out how to care about the journey if you actually want to have some level of enjoyment in your career. Otherwise every day genuinely will be a soulless repetition of the last.

There’s a reason why Camus wrote that one must imagine Sisyphus happy. If Sisyphus were to redefine the pushing of that boulder as a journey, and the rolling down of that boulder as a satisfying conclusion and new beginning, then this punishment is not as severe. Of course, this requires a lot of mental effort, but I think it’s necessary to live a life that you can actually be happy with.

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

https://www.javatpoint.com/difference-between-object-oriented-testing-and-conventional-testing#:~:text=In%20object%2Doriented%20testing%2C%20the,encounter%20in%20the%20real%20world.

Object Oriented testing focuses on the behavior of an object or class within an  object oriented system with its goal being to ensure any interaction or expected behaviors are correctly carried out when the system is used. This type of testing also heavily relies on ‘real world’ situations for example when writing test cases you would base your cases on things that the system is likely to interact with in the real world input wise which makes it easier to identify any possible behavioral issues within the system. There are three different testing phases which are commonly used in object oriented programming which are Unit testing, integration testing and system testing. Unit testing is used when testing classes or objects while isolated from the rest of the software, integration testing is used to verify that objects or classes are able to properly work together and system testing is used when testing an entire system to verify that the system itself works properly. Object oriented testing also requires the tester to have knowledge of a system’s inner workings in order to properly test it. This type of testing obviously is used on object oriented software which would be any software that is written using an object oriented language so in that aspect it is limited as object oriented testing would not be relevant or necessary to software which is not in the object oriented domain.

I found this article useful as it gets straight to the point when it comes to outlining the basic idea behind object oriented testing but it also chooses to compare it to conventional testing which helps the reader to differentiate between some of the different attributes of the two testing types as well as some of their similarities. This really helps when it comes to understanding why object oriented testing is defined as its own type of testing when their are already many other testing methods. This article helped me gain a greater understanding of object oriented testing which will help me to think more in depth about the cases I am able to write while testing in the future. The specific use of real world scenarios mentioned in this article was particularly interesting to me as I had not previously thought about how using real scenarios would typically provide more accurate results and or errors as compared to randomly selected scenarios which will also influence how I write test cases in the future.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

This week the pattern I decided to write about is from chapter 2. The pattern titled “Expose Your Ignorance” discusses something I’ve had to experience recently: letting those you’re working with fill the gaps in your knowledge. This section opens up with this quote by Jake Scruggs in “My Apprenticeship at Object Mentor”. The quote is “Tomorrow I need to look stupider and feel better about it. This staying quiet and trying to guess what’s going on isn’t working so well.” Opening this topic with that quote is impactful because I think a lot of people feel shame and would call themselves stupid for simple gaps in their knowledge when others have high expectations for them. It’s important to acknowledge that it’s okay to not know everything and be transparent about it instead of struggling alone while deadlines approach.

When I was working on a website with a group of other developers, we were all transparent with each other about our knowledge gaps for the tech stack we had to work with. This allowed us to play off of each other’s strengths and weaknesses. Some of us were more knowledgeable about the front end while others were more knowledgeable about what was required for the backend. I was more unfamiliar with what the front end required so I worked on the backend team. When we started working on the project, I was transparent about my lack of knowledge about JavaScript, routes, controllers, and HTTP requests. My team leader spent some time going over the material with me and provided some resources to research on my own. I then looked for more resources to learn. We also made an effort for everyone to learn a bit more about both the front end and the back end.

 In the text, it said, “Conceding to unspoken pressures and telling people what they want to hear is not a good way to build strong relationships.” I agree with this because our transparency made sure we were able to help each other grow and in turn strengthen our relationships with each other. Your reputation will be built off of your willingness to learn. There wasn’t any part that I could disagree with. When you’re honest about your ignorance you will end up picking up knowledge about a variety of technologies which will make it easier for you to adapt down the road.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

This week I decided to touch on static and dynamic testing. I wanted to find a blog that talks about different techniques for each type of testing. While searching I found the blog Static Testing VS Dynamic Testing – Key Differences testing by Kiruthika Devaraj. It first begins by generally defining the two types of testing. Devaraj first defines static testing as involving “testing the software without running it” and dynamic testing as involving “executing the program and testing its behavior in different scenarios”. They then go on to explicitly outline the differences in the next section. 

In the section titled “Differences Between Static Testing and Dynamic Testing”, they explain that static testing involves reviewing the documentation, design or code to check for defects and errors without executing the software. They also mention that this type of testing aims to identify issues early in software development when they are easier and less expensive to fix. They explained that dynamic testing involves executing the software and testing its behavior in different scenarios. They explain that during this process testers create test cases and run tests to identify defects and ensure the software meets the specified requirements. By testing the program against a variety of inputs, expected outputs, and error scenarios, this kind of testing essentially tries to evaluate the product’s functionality, performance, and security and ensure that it operates as predicted. In this section, the author uses bullet points and spacing to organize the information and make it easier to digest. 

The next section is a table that clearly outlines the differences in features like definitions, objectives, types of testing, timing, and results for static and dynamic testing. Static testing involves code review, walk-through, and inspection while the other involves unit, integration, system, acceptance, performance, security, and user acceptance testing. The author then explains how to choose between the two types of testing. They mention that it comes down to the specific requirements, objectives of the testing process, and desired outcomes. I enjoyed this article because the author got straight to the point when writing the article while clearly defining the use of each type of testing. I think the way they went about writing this informational piece was effective in keeping the reader’s attention by outlining the information in the simplest way possible. The use of bullet points and tables helped me to remember the information better. I am likely going to have to test my future personal projects so knowing the differences between the two types of testing and how to choose it was important to read about.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.