Category Archives: CS-443

Performance Testing My Patience

currentlycompiling

In the digital age, we have all grown accustomed to instant feedback from our technology. Old timers love to tell stories of what using the old dial up internet was like, usually paired with “I walked to school uphill, both ways”. It always seems to come with an undertone of kids these days are spoiled. However, I will be the first to admit that when something takes a moment too long to load, my first instinct is to pull up either pull up Task Manager and see what is running or check the wifi-speed. Should I work on being a bit more patient? Yeah. Should we all? Probably.

I digress.

The reason we have grown so accustomed to instant feedback is that it is the standard. Like any standard, how do companies measure and enforce it? Performance testing.

Performance testing is the practice of testing an application, program, or network’s performance. This includes speed, traffic handling, and stability although many other markers fall under this category.

Measuring and responding to performance markers leads to enhanced user experience and by extension increased revenue. For example, when waiting on a website to load and it takes too long, many people will click out before it even loads and look at another site. This directly translates into lost potential revenue due to poor performance.

The most effective way to use performance testing is to integrate it very early on in development. It is far more cost and time efficient to integrate early on in development; the initial set up is far less complex and there is less time needed down the line to rework performance issues, as compared to waiting to implement performance testing. Additionally, it is an effective tool to detect and prevent bugs before they become critical.

I really appreciated the insight this article provided. It is seldom that you think of performance testing when in the early stages of development, unless something goes wrong. Working code tends to be the goal. However, the benefits of doing so are hard to ignore. An important take away from this is that with any code you must consider the user-expectation (I like to think of this as if I am just writing code for myself to solve a one-off problem, I don’t care if it takes an extra few seconds to run my program. However, if I was sharing the program with others, it would be incredibly frustrating to them if my code took forever to execute.)  Additionally, prioritizing quality in the beginning saves many headaches later. Just because you do not test performance in the beginning does not mean you won’t have to go back and fix it once you do.  This is a lesson I will be sure to take keep in mind in the future. This will most likely look like making a conscious effort to make implementation choices that will support efficient performance in the long term as well as prioritizing quality overall.

This blog post was written in response to : https://abstracta.us/blog/performance-testing/why-performance-testing-is-important/

, ,

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

Why do We Spend so Much Money on Security Testing?

currentlycompiling

Data is the new currency of the digital age. It is constantly being collected, analyzed and sold. Data is an intangible thing; you can’t hold it in your hand. Is it any less valuable than money? I would argue that in some cases, it is more valuable than money. If it is more valuable than money, then there must be bad actors looking to gain access to it. There are. There are more people trying to get into these systems on the daily than all bank robberies in the last 100 years. However, unlike a bank that has a physical vault, data is stored in information systems. So how do you ensure that your data remains secure? By using security testing.

Security testing is an overarching term that refers to the process of identifying and addressing vulnerabilities within a system/application to safeguard data. This can take the form of identifying potential vulnerabilities by looking at code (white box testing), penetration testing (a form of black box testing), among many others.

This makes sense, however businesses are money focused….why do they spend the EXORBITANT  amount of money that they do on security testing?  Afterall, you are not gaining revenue by security testing. It is not  a direct correlation in the way that sales = profits.  According to the blog linked below, it comes down to reputation, financial losses and regulations.

Reputation is pretty self-explanatory: I am not going to be eager to hand over my bank information or social security number if I know that company has been involved in multiple data breaches. There is a necessary level of trust between a company and a customer in order to do business. If I do not trust that my information will be secure, I will choose a different company to do business with.

Financial losses are a multifaceted issue. There are the direct costs: if a company is attacked by ransomware, they will have to shell out $X to attempt to get their systems back. Then there are the less direct costs: the example given was that insurance companies will choose not to insure a company if they keep having security breaches. Choosing not to have adequate security testing means that a company is too risky of a business partner to do business with. Once a company loses insurance coverage, it is not a rosy outlook for the future. Insurance companies run the world.

Finally, in order to be commercially viable, software needs to meet regulatory security standards. This could be on an industry, state or international level. The need for enacting regulatory standards illustrates just how important security testing is.

Moral of the story: Security testing is about spending money to not lose money and being a good digital citizen. You need to protect everyone else’s information as if it were your own.

This blog post was written in response to : https://sdtimes.com/test/the-importance-of-security-testing/

, ,

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

Functional vs Non-Functional Testing

currentlycompiling

Functional testing is testing that focuses on how the code behaves in relation to technical and business requirements. It boils down to caring about what the system can do, not how it does it.

In comparison, non-functional testing is a broader term that encompasses basically everything else. This includes security testing, performance testing, usability testing, stress testing etc…

As an example, say I built a calculator program …

Functional testing would look like checking if 1+1 = 2 and 45/5 = 9

Non-Functional testing could look like testing how long it takes to calculate simple integer addition or making sure that no outside users could hack in and access your calculation history.

The key distinction between the two is the types of answers you can from the type of testing. Functional tests often tell you yes or no (does it do x when I do y?). Non-functional testing tends to give answers that are evaluated on a scale (How long does it take when..? How easily will the user be able to access this?)  

I found this article to be quite informative. It clarified in my mind how the two types differ. Although I am familiar with functional testing, I was not familiar with what falls under the umbrella of non-functional testing.  Generally speaking, it is often the case that as programmers we focus on functional testing. This makes sense, as working code has to do with input/output relationships. However, after learning about non-functional testing, I see why that is flawed. Non-functional testing represents the next level up in the hierarchy from the code. You can have working code that is objectively awful code. In order to improve your code, you need to pay consideration to the metrics of non-functional testing to assess how your code is performing, not just what it is performing. I can see how this becomes of particular importance once we start talking about a business level view-point rather than just a code/project level one.

As someone who hopes to found their own software company one day, this is particularly important. It illustrates the jump from code to business in testing metrics. I always have placed particular emphasis on learning computer science through the lens of that goal. Exploring this testing topic allowed me to identify a new point along the aforementioned seam between code and code for a business.

Additionally, understanding the different classifications of testing gives you the context to build better testing systems. Now that I know about functional vs non-functional testing, I will be able to analyze my own projects through that lens. I may think I have pretty solid testing in place for a piece of code, but upon further inspection I realize that I only tested what the code does, not how fast it will perform. Or vice versa, I may look at a project and realize that I was focusing so much on performance that the granular details of the code do not implement an elegant solution.

This blog post was written in response to : https://u-tor.com/topic/functional-vs-non-functional

, ,

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

BDD: It’s about Communication

currentlycompiling

Behavior Driven Development (BDD) is a software development approach that focuses on how the end user will interact with the application. This was created as an extension of Test Driven Development in an effort to bring customers into the development process in a meaningful way.

However, according to the article linked below, BDD is more about a philosophy and communication than an actual framework. The main complaints listed are than “Clients don’t care about testing” and “The client doesn’t want to write the specifications”. However, what these complaints fail to address is that BDD is a way to bring customers directly into the development process. It is not about writing their own specifications, it is about truly understanding the user experience and how we can directly support that throughout the development process.

As people on the technical side, it can be quite easy to get caught up in the nitty gritty details of what you are working on. Consequently, it is sometimes easy to lose sight of the bigger picture (aka, what product the customer will be interacting with). What BDD aims to do is bridge the gap between the developers and the users and inject the user directly into the middle of the development process. In essence, it is a tangible way to always have the customer in the room.

This is conceptually something I really agree with. It is the equivalent of a student pasting the assignment requirements at the top of the page before beginning to work (something that I have often done). It keeps your focus on the things that matter and contributes to an effective and efficiently developed solution.

Something that struck me about the post was this question that was posed: “How complicated would it be for you to explain to a 3 year old child how a bank transaction works?”  It served to highlight that part of the value in BDD is that on the tail end, it facilitates effective communication back to the customer. Just as with the 3 year old, a customer does not need to see the test cases that test the granular detail of the code, they just need to see what it does. This means that the tests used in BDD can then be used to demonstrate the behavior of the code in an easy to understand, non-technical format.

I was previously unaware of the value in BDD for communication until reading this post. I think that effective communication is something that is hyper-emphasized on the business side of things, but can be lacking on the technical side. The ability to integrate the customer into the testing structure and then communicate the testing back to them enhances the quality of collaboration and the end-product.  I am eager to delve deeper into other development practices that specifically support development by bridging the communication gap between developers and customers.

This blog post was written in response to : https://www.thoughtworks.com/insights/blog/3-misconceptions-about-bdd

, ,

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

The Lesson to Take From TDD

currentlycompiling

Test Driven Development….it admittedly feels a bit tedious to properly execute. …painful might be a more accurate descriptor.

In the simplest terms, Test Driven Development is a development strategy that involves writing a test first, then writing code only to satisfy this test (without breaking all the previous tests). Simple enough.

The problem with this? Many programmers have a love hate relationship with Test Driven Development.  In certain cases it can be an effective development strategy, however, it is feels slow and is tedious to properly execute. Given this, why do we use it? What is the real value in using this approach?

Uncle Bob would argue that it is the short development cycle that is most important. Writing the tests first requires that the development cycle increments are pretty much as small as possible. It is a way to enforce on a process level that developers break down their work into small and manageable pieces. This goes against the very natural inclination to solve the problem not a piece of the problem. This is why it needs to be addressed on a process level. TDD has nothing to do with the tests being written first, it has everything to do with writing the test first defines a small increment to code.

This is good news for the TDD haters, you don’t have to use TDD specifically. However, you should take a lesson from TDD and consider how you can apply it to your development process. Uncle Bob specifically notes that Test Last Development (TLD) has a similar effect to TDD.

As I am still new to TDD and still working through some katas, I will continue to do that. However, I personally think I will fall in with the group that should take a lesson from TDD and move on. I sometimes struggle to start working on a problem when I am looking at the problem as a whole or when I get stuck, so I really liked the way that TDD makes you put one foot in front of the other and just take the next step. However, I did not like that it can get in the way of being in a “flow state” of coding. I really enjoy it when I am coding and I am in a groove. That is a wonderful feeling. In that way, TDD feels like it sucks the joy out of coding. Uncle Bob’s analysis of TDD will inform my development process in that I will work on finding a way to implement small development cycles in a way that works for me. That might look like writing the tests first sometimes or it might look like mentally breaking down a problem in a TDD-like manner. However, I feel the freedom to learn from TDD without being pigeon-holed into using it exclusively just to get the benefits of it.

This blog post was written in response to : https://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-work.html

, ,

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

Exploring Design Patterns in Computer Science: A Beginner’s Perspective

Design patterns are essential concepts in software engineering, providing time-tested solutions to common problems. As an apprentice in computer science, understanding design patterns can significantly boost your coding efficiency and software design skills. During my learning journey, I found an insightful article, Java Design Patterns from GeeksforGeeks, that provided me with a solid foundation on design patterns. Here’s a summary of the article and my reflections on how it has shaped my learning experience.

Summary of the Selected Article

The GeeksforGeeks article Java Design Patterns covers the key design patterns used in Java programming. It introduces three main types of design patterns—Creational, Structural, and Behavioral. Each category is explored with practical examples and explanations that break down the complexities of design patterns into digestible information. The article also touches on popular patterns like Singleton, Factory, Decorator, and Observer, providing clear definitions and illustrating their use cases in real-world Java applications. It serves as an excellent resource for beginners to grasp how design patterns can improve code readability, reusability, and maintainability.

Reason for Choosing this Resource

I chose this article because GeeksforGeeks is known for delivering educational content tailored to both novices and experienced developers. I needed a source that could present design patterns clearly and practically, specifically for Java programming, which I am currently studying. The website’s step-by-step approach to explaining concepts, accompanied by code snippets, resonated with my learning style. As a beginner, I was looking for a resource that could demystify design patterns without overwhelming me with technical jargon, and this article did exactly that.

Personal Reflection and Key Takeaways

The material was enlightening, especially in how it framed design patterns as reusable solutions to software design issues. Before reading the article, my understanding of patterns like Singleton or Factory was limited to theoretical concepts, but the examples provided helped me visualize their practical applications. One major lesson I took from this article is the importance of the Singleton pattern, which ensures that a class has only one instance and provides a global point of access to that instance. This concept is essential in areas like database connections, where having multiple instances could lead to conflicts.

Additionally, learning about the Factory pattern—a creational pattern that allows for the creation of objects without specifying the exact class—opened my eyes to how flexibility and scalability are achievable in code. This pattern is especially helpful when dealing with large projects where new object types might frequently need to be added.

The article not only strengthened my grasp of object-oriented principles but also inspired me to think more critically about how I structure my code. It shifted my perspective from merely getting the code to work, to considering how to design it efficiently for future use and maintenance. I now see design patterns as a roadmap to writing better, more scalable code.

Future Application of Design Patterns

Moving forward, I plan to incorporate these design patterns into my coding work practices, particularly in my Java projects. The Singleton pattern will be useful in managing system-wide resources, while the Factory pattern will aid in developing modular code that can easily evolve. Understanding these patterns equips me to write code that is not only functional but also adaptable, which is crucial as I delve into larger, more complex projects.

In conclusion, design patterns are invaluable tools for every software developer. Thanks to resources like the GeeksforGeeks article, I now have a clearer understanding of how to implement these patterns in Java, and I look forward to applying them in my future projects.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Week 18B – C Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll continue with one I’m not the most familiar with, C! I’ve worked in small amount of C in classes at Worcester State, but have little experience outside of that. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

If you haven’t already read my other blog post on Python testing, feel free to read it right here!

Week 18A – Python Testing

For learning about unit testing in C, I consulted this article on the subject: https://interrupt.memfault.com/blog/unit-testing-basics

It seems like unit testing in C is a lot more barebones compared to Java, which in my experience utilizing C, makes sense for the language. A lot of features primarily used in Java, like object-oriented structures aren’t available in C (to my understanding, could totally be wrong).

For one major aspect, there seems to be only one assertion command in C, just simply “assert”. Theres no assertTrue, assertFalse, assertThrows, or assertEquals, just simply “assert”. And from the example given below: 

#include <assert.h>

// In my_sum.c
int my_sum(int a, int b) {
  return a + b;
}

// In test_my_sum.c
int main(int argc, char *argv[]) {
  assert(2 == my_sum(1, 1));
  assert(-2 == my_sum(-1, -1));
  assert(0 == my_sum(0, 0));
  // ...
  return(0);
}

It seems the “assert” function comes from the <assert.h> library, much like the JUnit librarys used in Java. But more importantly, it seems that “assert” is the equivalent of “assertEquals”.

It also seems like Unit Testing in C is best implemented with tools outside of a compiler for C. The ones mentioned in the article in specific were CppUTest, Unity, and Google Test. For the rest of the article, the use examples using CppUTest. It was interesting to hear one of the options being called Unity, which is the name of a game engine, which, while not written in C, is written in a mixture of C# and C++, which are both offshoots of C. Makes me wonder how testing in a gaming engine works, perhaps it’s something to look at in a future blog post, hint hint, wink wink.

CppUTest seems to implement the same SetUp() and Teardown() functions that JUnit can employ, which is really good, as these methods are important for testing multiple methods. It also seems to have more then just an Equals assertion, even though the example used is another equals example.

This gets me more interested in C, as I have been told understanding C allows you to understand other languages much more clearly. Perhaps I’ll take a deeper dive some day, who knows! Until next time, my readers~!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 18A – Python Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll begin with the one I’m the most familiar with, Python! I’ve worked with Python in small amounts in the past, and have an understanding a lot of it’s syntaxes are similar to java’s, albeit simpler. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

For this, I’ll be looking at the official page for unittest on Python’s website, here:

https://docs.python.org/3/library/unittest.html

Right off the bat, I’m really interested in the fact that unittest is actually based directly off of JUnit! Which means a lot of the syntax, formatting, and framework is quite similar, just modified to fit the mold of Python.

Looking at the snippet they gave as an example…

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

In this, it seems the way you define test blocks is by having a class with (unittest.testcase) and then doing “def” to define each test case.

Even the assertions are the same and written near identically, as the first three use assertEqual, which is identical to javas assertEquals, minus the s, and assertTrue and assertFalse, which are also identical to their java counterparts. assertRaises, which is used in the third test, seems to be Python’s equivalent to assertThrows, however, it seems to be a bit different in comparison. assertRaises seems to identify a specific kind of exception being raised, whereas assertThrows would just identify any exception in general.

The last line also is a block of code that allows an easy way to run all the tests, so when you run unittest.main() in a command line, it will automatically run all the tests and display the results.

There also seems to be a whole bunch of different command line options to display results and modify the ways in which its run. As an example, theres “-v”, which stands for verbosity, much like the bash command, which shows the results of each individual test being run, like below:

test_isupper (__main__.TestStringMethods.test_isupper) ... ok
test_split (__main__.TestStringMethods.test_split) ... ok
test_upper (__main__.TestStringMethods.test_upper) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

It seems extremely interesting and makes me want to learn more Python, which would definitely help me in my career in all sorts of ways! Next blog we will be looking at how unit testing works in C. Until then!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Behavior Driven Development

Behavior Driven Development ( BDD ) is a test practice that makes sure there is good quality by automating test before or during system behavior specification. BDD test focuses on facing scenarios that describe the behavior of a story, feature, or capability from a user’s perspective. When the tests are automated they make sure that the system constantly meets the required behavior.

The Behavior Driven Development Process

The BDD process has three phases to it. The discovery phase, formulation phase, and the automation phase.

1.) Discover phase: This phase is where the user creates the initial acceptance agenda for the feature. This phase is usually done in a collaborative manor, each team member is contributing.

2.) Formulation phase: This phase is where the acceptance agenda sets into detailed acceptance tests, as the backlog item gets closer to implementation. This phase also incorporates specific examples of the behavior.

3.) Automation phase: This phase is where automation tests are automated to run constantly. This is to make sure that the new system supports the new behavior.

Benefits of Behavior Driven Development

1.) Early detection of errors / defects: When you automate tests in the early stages of development process, you can identify and address the issues. BDD allows for the early detection of defects.

2.) Faster Flow and Time: when using BDD, you can reduce the errors, rework, and replan. BDD accelerates the flow of the development process. Developers can produce features / products faster and more efficiently.

3.) Stronger Test Coverage: BDD allows for a more comprehensive test coverage that focuses on the user behavior and scenarios. Both common and edge cases are tested as well.

4.) Clear understanding: BDD can be plain and clear to understand, because specific scenarios are used to describe the behavior from a user’s point of view. This helps the development to fully understand the requirements and whats going on.

Why I chose this resource

I chose this article ” Behavior Driven Development” because it provided a detail look of a very important test method that goes in conjunction with the technical and business aspect of testing. Understanding BDD is important in today’s society of software development, for giving an efficient and more user friendly user products.

Personal Reflection

This article increased my understanding of BDD and the use of it in software development. I learned a lot about how BDD strengthens collaboration and communication between the business side of things and the technical side of things. This helps to ensure that user’s expectations and requirements are met. The new found knowledge will be extremely valuable in my future endeavors because I will incorporate this method in my future projects. This will help to improve the development process and product efficiency and quality. Also, by using BDD I can make sure that all requirements and specifications are met.

The full article is here: https://scaledagileframework.com/behavior-driven-development/

From the blog CS@Worcester – In&#039;s and Out&#039;s of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

Static Testing vs. Dynamic Testing

Testing in software development is important because it helps to deliver efficient and user friendly products to the end user. It also provides the developers with a chance to improve upon the product. Static and Dynamic testing are two important techniques used in software development.

Static Testing

Static Testing has various names like Verification Testing, Non-execution Testing, etc. This testing technique is used to identify defects in software without actually executing the code. This method usually includes manual and automated evaluation of the software and the code. Developers use this method usually in the beginning stages of the development process to catch issues early on, which will also lead to be easier and cheap to fix. This method focuses on reviewing the test cases, test scripts, test plans, and source code.

Static Testing Techniques

1.) Informal Reviews: Developers review each of the documents and give feedback

2.) Walkthroughs: Someone presents the product to the team and someone else takes notes.

3.) Technical Reviews / Code Reviews: review the technical specifications and the source code to make sure everything meets the requirements and standards.

4.) Inspection: Check for defects. Developers usually review the process with a checklist to help identify and record for defects.

Dynamic Testing

Dynamic Testing is a technique that analyzes the dynamic behavior of the code by actually executing it. This method makes sure to check that the software functions correctly and that there are no underlying issues / conditions. Sometimes developers use this method in conjunction with black box or white box testing to provide more realistic results.

Dynamic Testing Techniques

1.) White Box Testing: Examines the internal code structure. You need to actually have the internal code (source code)

2.) Black Box Testing: Checks the functionality without the actual internal code (source code) .

Benefits of both Static Testing and Dynamic Testing

1.) Early detection of defects

2.) Cost efficient

3.) Showcases runtime errors

4.) Reliability

Why I picked this Resource

I chose the article “Static Testing vs. Dynamic Testing” because this article gave me a more detailed and in depth look between two very important testing methods that are currently being used in todays society. It is very important to understand these two testing methods in the software development process because they can deliver efficient and user friendly products to the end user. This article also aligns with what we have learned in the course, making it relevant to talk about and to understand.

Personal Reflection

This article deepened my understanding of static and dynamic testing. I was able to learn a lot about these two testing methods that I did not know, even the many benefits that each method has. Knowing how crucial these two methods are in the software development process and what I know now, this knowledge will help me on my future endeavors when approaching new projects in regards to testing .

The full article is here: https://www.geeksforgeeks.org/difference-between-static-and-dynamic-testing/

From the blog CS@Worcester – In&#039;s and Out&#039;s of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.