Performance Testing is a subject I just recently discovered is included in the Software Quality Testing umbrella term. Outside of casually monitoring CPU and GPU usage while using demanding software, I have little knowledge of what Performance Testing is. As a future worker in the Computer Science field, knowing how to report and minimize hardware stress must be an invaluable skill.

During my search to understand what Performance Testing is, I found an article written by Tricentis that included an in-depth explanation for each step (or deviation) of Performance Testing. Before going into detail, Tricentis highlights that performance testing is a direct solution to ensuring the stability and scalability of software. If performance testing is ignored, then users may encounter issues with speed, crashes, or data loss within their application. Testing seems to flawlessly integrate with CI/CD models, as testing should occur whenever a working model is available. This allows the development team to fix issues early before they sink too deep into the product’s foundation. Within the realm of performance testing, some subtests aim to find results for specific metrics. A few that I was unfamiliar with are as follows. Regression tests seek to test two states of the program, one being the current model, and the other being one with experimental changes. Both of these models work together to compare the hardware performance. These are used to highlight whether changes from the most recent version are more damaging to the product. Functional tests focus more on the software aspect of the product. Using this test will yield results on whether the UI elements, APIs, etc are all functioning correctly. Lastly, load testing seeks to put the product under great stress by simulating several concurrent users. Testing with this will give the developers insight as to how their product will function once published to the general public. Metris from load testing will help reinforce the product before it can fail after its initial release.

Performance testing will yield several useful metrics to guide the development of the product. These metrics include hardware bottlenecks, response time, and load time. Issues about these metrics must be addressed during the development process as they directly impact the reliability of their product post-release. Untested hardware is an active detriment to the developers, and will further damage the development process. Following the idea of testing software ‘frequently and consistently’, developers must also view how the current state of their product affects the hardware it will operate on.

-AG

Source: https://www.tricentis.com/learn/performance-testing

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

JavaScript is a programming language completely foreign to me. At one point in the near future, I see myself learning the basics just to gain general exposure to it. It differs enough from my first object-oriented language, that being Java, to the point where it seems valuable to have some experience in it. With this in mind, I began my search to see what testing framework would work for this language and how tests are conducted differently.

In my search, I discovered this testing framework named Jest. This is a testing framework that is most known for testing Javascript but has also seen usage with other languages such as Angular and React. According to the author of the blog post The Pros and Cons of Different Test Tools – Jest, Craig Risi, he immediately states this testing framework is much more user-friendly than others. Jest does not require the users to install packages or other external dependencies, as the framework has them already included. Furthermore, the included dependencies are often built on frameworks of other languages, such as Mocha or Chai, which makes Jest an incredibly flexible testing framework. An important inclusion Risi made to his blog post was the inclusion of all features Jest offers out of the box. These range from topics I’m knowledgeable of, such as Mocking and Unit Testing, and some that I’m new to, such as Snapshot Testing and Asynchronous Testing.

Towards the end of Risi’s blog post, he mentions the direct pros and cons of using Jest. As previously mentioned the versatility between languages, easy start-up, and abundant features are a testament to its practicality. Unfortunately, no testing framework is flawless. Several of these issues originate from the sheer size of Jest. Downloading this framework and testing smaller projects offer an issue of scalability. There are countless smaller frameworks, in terms of digital size and complexity, that are better suited for testing software. Additionally, all the features Jest includes come with their own learning curve. Users may never utilize some features as the scope of their testing does not call for Jest’s extensive collection. With both the pros and cons in mind, Jest is incredible in what it can achieve but development teams must consider the scale of their project to determine whether using it is appropriate. Reflecting on my experience with testing frameworks, I can understand the value of having that much utility from one framework, yet I don’t see myself creating a project ‘so big’ that would call for it’s entire library of features.

-AG

Source: https://www.linkedin.com/pulse/pros-cons-different-test-tools-jest-craig-risi

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

In last week’s class, we were tasked with creating an activity related to our course material. Our group decided on behavior-driven development (BDD) since it is related to test-driven development, which we discussed in class. BDD’s approach is user-focused and prioritizes understanding between the development team and users, but it has yet to be discussed in class. Since the post was well-organized and informative, focusing on aspects that could help developers improve their code, I decided to talk about BDD for my blog post this week. 

The blog post “Behavior-driven development principles and practices,” by Philip Rogers outlines the basics of BDD, detailing its history, principles, and practices. Phillip explains that BDD is centered around three principles: what the software could do, what the software should do, and what the software does.

1. What the Software Could Do: This principle involves understanding what the customer wants from the software. They use discovery workshops to outline what the developers should prioritize and resolve any confusion between the users behaviors and the team.
2. What the Software Should Do: This principle focuses on creating documentation in a human and computer readable format. This includes the given-when-then format that describes the user’s behaviors and how the software should respond. 
3. What the Software Does: This principle focuses on using the documentation or scenarios to create automated tests and improving the code until it aligns with the customer’s requirements and the team’s goals.

The blog post also discusses Gherkin, a language used in BDD to bridge the gap between human and computer understanding. The syntax used in Gherkin helps capture user scenarios and articulate how the automated tests should work to align with those scenarios. Philip also explains the benefits of BDD, such as improved collaboration and reduced rework, and the cons, including high level of business engagement and the lack of compatibility with traditional software development. 

After reading this blog post, I better understood the BDD process and why these principles are in place. It highlighted why there would be a need to deviate from or expand test-driven development. There should be a focus on how users interact with the system using communicative language to reduce the creation of faulty features.  

In the future, I plan on being mindful of the user’s experience and creating software with my team to meet the users and, in turn, the team’s expectations. I will also look into a Gherkin and try to understand the syntax better to produce better tests and end products. 

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

Link to blog: https://medium.com/swlh/intro-to-javascript-testing-with-mocha-1366dad9b973

For the next (and last) couple weeks of class, we are required to create our own in-class activity as if other students were going to use it. We were tasked with choosing something different than we have done already, so my group decided on testing JavaScript programs with the Mocha framework. I personally have no experience with Mocha, but I do have a tiny bit of experience with JavaScript, so I was interested to learn more about how different testing looked compared to what I was currently experiencing. This is how I found Valerie Foster’s blog post Into to JavaScript Testing with Mocha. Here’s what I found. 

Foster does give a few instructions on how to install the Mocha framework to your project, but I’ll mainly focus on the pros and cons of testing within the framework. They include a codeblock of a simple test, however it was not 100% clear to me at first what each line meant. Here are a few things included in the codeblock, and what they do:

• describe(string, function)
  • According to Codeacademy.com, the describe function groups tests together and uses the first parameter, the string, to explain that group. The second parameter, the function, is a callback function which has ‘it’ tests (I’ll get to that in a moment)
• it(string, function)
  • The it function is similar to the describe function, as its parameters are the same. However, the string it accepts is instead used to explain what the test itself is checking for. So, for example it(‘should //do something when //condition’, function(){})

Foster then discusses some customization options for Mocha, but then specifies their favorite assertion library in Mocha, called chai. One of the key benefits of this library is that it might make the test functions easier to read (e.g., going from assert.equal(a, b) to expect(a).to.equal(b), according to Foster). 

I selected this article because I wanted to have more of a background on Mocha and testing with Javascript since it is going to be our project. Also, Foster seems capable and comfortable with Mocha and JS, and makes it easy to understand what is going on in tests with a framework I’ve never seen before. A good beginner’s guide is always helpful to a fresh start.

I liked this blog because it felt informative and informal; like I was being taught something new but not in a super serious tone (Foster shared their favorite terminal customization was a Nyan Cat reporter). I learned a bit more about how testing is done in JavaScript, including describe and it functions. This affected me by boosting my confidence in my ability to assist my group with our assignment and it encouraged me to learn more JS and Mocha as a whole. I expect to apply such learned knowledge to future web applications and perhaps even past projects.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

This week I decided to revisit Behavior-Driven Development, I’ve chosen this topic because, like Pairwise and Combinatorial Testing, understanding BDD prior to engaging in any related activities can significantly enhance your comprehension and application.

Behavior-Driven Development, or BDD, is a technique that aims to align software development with the expected behavior of the system. It focuses on making sure everyone is on the same page regarding how the software should work. Instead of just writing technical tests, BDD emphasizes describing the system’s behavior in plain language that anyone can understand. BDD promotes test automation by turning scenarios into executable specifications. Automated tests are written to verify that the system behaves as described in the scenarios. Instead of dry lists of requirements, scenarios showcase how users will interact with the app.

BDD is a collaborative approach that gets everyone speaking the same language. By focusing on how the app should behave, it reduces misunderstandings, catches bugs early on, and keeps your project on track. Additionally, by involving stakeholders in the creation of scenarios, BDD fosters ongoing communication and feedback throughout the development process. This collaborative approach helps build a sense of ownership and accountability among team members, which ultimately leads to better
outcomes.
A pro to BDD is the scenarios and examples you create will double as living documentation. This means the documentation stays up-to-date with the evolving app, reflecting the latest features and functionalities.

Of course, Behavior-Driven Development has its cons, One common challenge is writing effective scenarios that accurately capture the desired behavior of the system. It can be tough to strike the right balance between too much detail, which can lead to fragile tests, and too little detail, which can result in ambiguity. Additionally, BDD requires keeping scenarios up to date as the system evolves. We are constantly coming up with new features for our projects, and scenarios may need to be updated to reflect these changes. Its important to note, BDD is a powerful tool, but it’s not a foolproof solution. There’s still room for miscommunication, so clear communication is key. BDD promotes clear communication, but it doesn’t eliminate the need for it altogether.

In practice, teams often use tools like Cucumber, SpecFlow, or Behave to implement BDD. These tools provide features for writing and executing scenarios, as well as generating reports to track the status of tests. By using these tools, teams can streamline the BDD process and ensure that scenarios are written and executed efficiently.

Blog Post: https://semaphoreci.com/community/tutorials/behavior-driven-development

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

 I find the assertion that one is never done learning to be very true
to life. One’s skills as a software developer should be iterated upon just
like the very programs we craft. The section on perpetual learning
provided  many interesting examples of ways to tackle improving one’s
own knowledge base and skillset. I want to cover some of my favorite
sections in this blog post and over the course of the next couple blog
posts.

Expand Your Bandwidth

I constantly get the feeling that my knowledge in my career is always much
shallower than it should be. The suggestions provided at the start with
Google Reader and following software luminaries seemed interesting, but I
was much more interested in looking at online courses and podcasts. I want
to be able to constantly expand my knowledge base and explore new
horizons.  This reminds me of when I was keeping up to date with a
subreddit that was all about mesh networks and peer-to-peer computing. It
sprung up in the aftermath of network neutrality being struck down, and a
lot of people on there were proposing creating a giant open source mesh
network to combat predatory internet service providers. It had the overly
ambitious goal of decentralizing the internet which ,suffice to say, has not
come to pass yet, although I’ve heard that the emergent Web 3.0 is supposed
to be it. I was fascinated by the ingenuity of using a bunch of Raspberry
Pis to create mesh networks all around a city. I want to reignite some of my
passion for obtaining new knowledge and explore what is new today. I know
A.I. has gotten a lot of publicity, to the point of becoming something like
a buzzword, but I want to see what the other sectors of the tech industry
are working on. Thanks to writing this blogpost I went and looked to find
new sources of information. I even started perusing reddit, specifically in
the technology and programming tag,  again to search for any new and
interesting developments. I have already checked out the r/webdev amd
r/learnprogramming for some tips.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

 I find the assertion that one is never done learning to be very true
to life. One’s skills as a software developer should be iterated upon just
like the very programs we craft. The section on perpetual learning
provided  many interesting examples of ways to tackle improving one’s
own knowledge base and skillset. I want to cover some of my favorite
sections in this blog post and over the course of the next couple blog
posts.

Expand Your Bandwidth

I constantly get the feeling that my knowledge in my career is always much
shallower than it should be. The suggestions provided at the start with
Google Reader and following software luminaries seemed interesting, but I
was much more interested in looking at online courses and podcasts. I want
to be able to constantly expand my knowledge base and explore new
horizons.  This reminds me of when I was keeping up to date with a
subreddit that was all about mesh networks and peer-to-peer computing. It
sprung up in the aftermath of network neutrality being struck down, and a
lot of people on there were proposing creating a giant open source mesh
network to combat predatory internet service providers. It had the overly
ambitious goal of decentralizing the internet which ,suffice to say, has not
come to pass yet, although I’ve heard that the emergent Web 3.0 is supposed
to be it. I was fascinated by the ingenuity of using a bunch of Raspberry
Pis to create mesh networks all around a city. I want to reignite some of my
passion for obtaining new knowledge and explore what is new today. I know
A.I. has gotten a lot of publicity, to the point of becoming something like
a buzzword, but I want to see what the other sectors of the tech industry
are working on. Thanks to writing this blogpost I went and looked to find
new sources of information. I even started perusing reddit, specifically in
the technology and programming tag,  again to search for any new and
interesting developments. I have already checked out the r/webdev amd
r/learnprogramming for some tips.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

 I find the assertion that one is never done learning to be very true
to life. One’s skills as a software developer should be iterated upon just
like the very programs we craft. The section on perpetual learning
provided  many interesting examples of ways to tackle improving one’s
own knowledge base and skillset. I want to cover some of my favorite
sections in this blog post and over the course of the next couple blog
posts.

Expand Your Bandwidth

I constantly get the feeling that my knowledge in my career is always much
shallower than it should be. The suggestions provided at the start with
Google Reader and following software luminaries seemed interesting, but I
was much more interested in looking at online courses and podcasts. I want
to be able to constantly expand my knowledge base and explore new
horizons.  This reminds me of when I was keeping up to date with a
subreddit that was all about mesh networks and peer-to-peer computing. It
sprung up in the aftermath of network neutrality being struck down, and a
lot of people on there were proposing creating a giant open source mesh
network to combat predatory internet service providers. It had the overly
ambitious goal of decentralizing the internet which ,suffice to say, has not
come to pass yet, although I’ve heard that the emergent Web 3.0 is supposed
to be it. I was fascinated by the ingenuity of using a bunch of Raspberry
Pis to create mesh networks all around a city. I want to reignite some of my
passion for obtaining new knowledge and explore what is new today. I know
A.I. has gotten a lot of publicity, to the point of becoming something like
a buzzword, but I want to see what the other sectors of the tech industry
are working on. Thanks to writing this blogpost I went and looked to find
new sources of information. I even started perusing reddit, specifically in
the technology and programming tag,  again to search for any new and
interesting developments. I have already checked out the r/webdev amd
r/learnprogramming for some tips.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

 I find the assertion that one is never done learning to be very true
to life. One’s skills as a software developer should be iterated upon just
like the very programs we craft. The section on perpetual learning
provided  many interesting examples of ways to tackle improving one’s
own knowledge base and skillset. I want to cover some of my favorite
sections in this blog post and over the course of the next couple blog
posts.

Expand Your Bandwidth

I constantly get the feeling that my knowledge in my career is always much
shallower than it should be. The suggestions provided at the start with
Google Reader and following software luminaries seemed interesting, but I
was much more interested in looking at online courses and podcasts. I want
to be able to constantly expand my knowledge base and explore new
horizons.  This reminds me of when I was keeping up to date with a
subreddit that was all about mesh networks and peer-to-peer computing. It
sprung up in the aftermath of network neutrality being struck down, and a
lot of people on there were proposing creating a giant open source mesh
network to combat predatory internet service providers. It had the overly
ambitious goal of decentralizing the internet which ,suffice to say, has not
come to pass yet, although I’ve heard that the emergent Web 3.0 is supposed
to be it. I was fascinated by the ingenuity of using a bunch of Raspberry
Pis to create mesh networks all around a city. I want to reignite some of my
passion for obtaining new knowledge and explore what is new today. I know
A.I. has gotten a lot of publicity, to the point of becoming something like
a buzzword, but I want to see what the other sectors of the tech industry
are working on. Thanks to writing this blogpost I went and looked to find
new sources of information. I even started perusing reddit, specifically in
the technology and programming tag,  again to search for any new and
interesting developments. I have already checked out the r/webdev amd
r/learnprogramming for some tips.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.