Tag Archives: CS@Worcester

Functional vs Non-Functional Testing

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

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

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.

Intro: Software Process Management

This post serves as the starting point of a series of blog post that will be used to dive deeper into the topic of Software Process Management.

-EA

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

Intro: Software Construction, Design and Architecture

This post serves as the starting point of a series of blog post that will be used to dive deeper into the topics of Software Construction, Design, and Architecture.

-EA

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

Introduction- Brandon Njuguna

His this is my blog called Computer Science From a Basketball Fan. Im excited to Publish on this new blog and learn from other bloggers. This blog will be primarily used for CS-343 and CS-348 as of right now. Hope for the best!

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Karl R. Wurst 2023-01-14 09:00:17

Very productive three-day sprint on the GitKit! This is a kit to let students learn Git workflow in the context of a real Humanitarian FOSS project. Great work from Stoney Jackson, Grant Braught, and Cam Macdonnell. We will be demoing this at in Toronto. sigcse2023.sigcse.org/details/

From the blog Karl R. Wurst by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.

Karl R. Wurst 2023-01-03 07:40:20

Starting a day and a half of AWS training to learn how to deploy LibreFoodPantry on K8s! A former (20+ years ago ?) student is now working for AWS and volunteered to do the training for our coordinating committee. And thanks to AWS for providing credits for open source projects!

From the blog Karl R. Wurst by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.

Karl R. Wurst 2023-01-01 15:46:03

Since all the cool kids are doing it…
GitHub contributions and GitLab contributions

I'd rather not host my work with a company that doesn't respect my licenses.

From the blog Karl R. Wurst by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.

Karl R. Wurst 2022-12-30 17:10:52

I am testing syndicating my toots to my blog. This should go to my blog, and from there it should be syndicated to the CS@Worcester blog.

From the blog CSWorcester – On becoming an Eccentric Professor… by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.