Before being exposed to JUnit, my only experience with automated testing was through CxxTest while I was learning C++. Once I started to learn JUnit both the syntax and general format seemed to ring a bell. This caused me to check back at my previous C++ programs to find that the assertion-based testing was identical to that of JUnit. After seeing these two side by side I was curious about the comparisons between these two testing frameworks and whether CxxTest had any advantages over that of JUnit.

While looking for an article discussing the full capabilities of CxxTest, I stumbled upon a blog, Exploring the C++ Unit Testing Jungle by user @noel_llopis, which seemed to provided extensive explanations of each popular testing framework for C++ at the time. Do note that this post was written in 2010, so popular testing frameworks from then may have faded into obscurity and new frameworks may be used in their place. My main allure to this article was Llopis’s section describing his experience with CxxTest and how testing frameworks required a little more work from the user back in 2010. Llopis praised CxxTest for it’s relative simplicity in how it’s imported into a program and how it requires much less dependencies. From his explanation, I’ve learned that testing frameworks used to require certain formatting within the file and potentially other libraries for the tests to function. CxxTest, similar to JUnit, can operate by itself with much less dependencies than it’s competitors (at the time). A feature that JUnit lacks that CxxTest contains is the ability to natively mock objects. JUnit does have this ability, but requires the user to add another resource to JUnit meanwhile, CxxTest has this functionality immediately. One downside that the author does mention is that CxxTest did require “use of a scripting language as part of the build process”(Llopis), this may create a barrier of entry to less experienced developers.

While comparing these two testing frameworks, I found myself asking a new question of ‘how accessible or inaccessible were testing frameworks of the past’. Llopis seemed to be enthusiastic about features that I held to be common for all frameworks to have. Additionally writing about this did make me wish that I spent more time in the past programming with C++ outside of classes. Reading this did help expand my knowledge of how CxxTest operates, so when I do inevitably go back to refine my C++ skills I’ll be ready to pickup this framework once more. Between JUnit and CxxTest, there are many surface layer similarities, as both are unit testing frameworks. The differences seem to lie in smaller features that some developers may depend on, such as mocking. After having experience in both I find it hard to chose one or the other as they both generally function the same and have similar levels of accessibility.

-AG

Source: https://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle

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

Throughout my experience with Software Quality Assurance, I’ve used two different types of testing frameworks. The most recent is JUnit as I’ve just learned how to use it earlier this year, and the other being CxxTest which I’ve forgotten most of (including its name) until writing this. Each of these operates for different languages, JUnit for Java, and CxxTest for C++. The differences between these two made me curious whether a framework worked for more than one language at once. Note, that frameworks such as CTest that work for both C and C++ I do not include as both exist within the C family. As I searched for a framework that answered my question I stumbled upon Selenium and subsequent articles comparing it to that of JUnit. These comparisons drew my attention and sent me down a path to understand what Selenium is.

Before getting into specifics I must introduce a few definitions that help differentiate these two frameworks. Unit testing is the method of testing smaller increments of source code to ensure that each ‘unit’ works as intended and meets the developers’ specifications. This lays the foundation for later development. End-to-end testing focuses on testing components where the user interacts with the program directly. This tests components such as UI and web applications. JUnit focuses on unit testing with code programmed in Java meanwhile, Selenium focuses on end-to-end testing with multiple different languages including Java. Fundamentally these frameworks are testing different aspects of software development, therefore any comparison between the two must be taken with a bit of nuance.

With definitions aside, we can now talk about what makes these frameworks unique. A community post on StackShare, JUnit Vs Selenium, gives a concise view into what make these frameworks differ. My experience with frameworks has only existed within IDEs however, Selenium is supported on browser and web driver tools. Additionally, Selenium tests run within a browser, meanwhile JUnits require a Java Virtual Machine to be created. One downside of Selenium is its requirements for dependencies, as opposed to JUnit which can be imported into your program. I’m more partial to JUnit as I only have experience with back-end development, so Selenium isn’t directed towards a developer such as myself. With that being said, those who are more experienced in front-end development may find the requirements for dependencies and browser configurations to be a small cost for its flexibility with testing.

I have a little experience with front-end development, so I can understand how the tools provided by Selenium could be invaluable. A lesson I’ve learned from this dive into Selenium is that all aspects of development (Ex: Front vs Back end) will require some form of automated testing. Additionally, testing that may be easy for one department may be more complex for another. With these different areas of testing also come different methods. End-to-end testing will be noticeably different than unit testing, as each method focuses on a specific function of the software.

-AG

Source: https://stackshare.io/stackups/junit-vs-selenium

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

Confront Your Ignorance

This pattern is about confronting your ignorance. After going through the “Expose your ignorance” pattern, where you identify gaps in your skillset, the next step is to confront those gaps. The main problem that comes from this pattern is that there are techniques and tools that need to be learned, but the process of actually learning these techniques in unclear. Some of these may be techniques that everyone already knows, so there is an expectation that everyone be competent in that area.

The solution to this pattern, with the list generated from “Expose your ignorance”, is to pick an item from that list and actively fill the gaps for that item. How this can be done is a matter of preference. Some prefer to research everything they can about a topic, such as introductory articles and forums. Others prefer a more hands on approach by going straight into the topic by building a simple project. Although confronting your ignorance is mostly an individual task, asking mentors and experienced people is important to learn what information they can share with you. Asking mentors can also be beneficial as they may have learned tricks that they found themselves that may not be discoverable through documentation.

As mentioned before, this pattern is do be done after exposing your ignorance. Exposing your ignorance is a critical step because it makes the gaps in your knowledge public, which makes your team aware of those gaps and your learning ability. Having your gaps be on display for your team encourages an environment where failure and learning are acceptable as they both play a large role in an apprentice transitioning to become a journeyman and so on.

Conclusion

This pattern is helpful to me because confronting my ignorance is something I struggle with at times. The pattern states that exposing your ignorance without confronting can lead to excessive humility and helplessness which are feelings I have had in the past, so this pattern helps to give some encouragement to start confronting that gaps in my knowledge. After reading the patterns “Expose your ignorance” and “Confront your ignorance”, I feel much more confident in the future on how I can improve my skills in a methodical manner.

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.

Security testing is an important part of software testing, it makes sure to find any weaknesses in the software and if our data is protected from intruders. Security testing is important because it helps us ensure that our software has no weak spots and that our data and information are safe. There are so many versions of security testing like password cracking, penetration testing, and vulnerability. Those three topics are some of the main ideas of security testing and understanding the importance of keeping personal information safe. Password cracking testing is when the system identifies weak passwords and helps make sure that people use stronger passwords. Penetration testing is done by assessing the system by using different techniques, the purpose of it is to protect the important data of the users who don’t have access to the system. Vulnerability testing is used to identify the weakest attributes in the system that can be used by destructive software. A lot can cause the software to be vulnerable like a bug in the software, wrong software testing, and the presence of a bad code. 

I chose this topic because security testing is important in our software testing class and this blog has a lot of information on how it works. It’s important to know more about how our private data is saved from hackers and how safe our software is. I believe that this helped me learn more about security testing like how penetration testing uses different techniques like the black box and white box testing method to detect any vulnerabilities in our software. Security testing is to make sure that applications are not able to leak private information and can handle a threat like hackers. I already knew before reading how important it is for our information and making sure that our passwords are not easy for hackers to figure out but I thought penetration testing was interesting to learn about because I didn’t know it used so many different techniques to find any vulnerabilities. Security testing is about keeping our information safe as well as our software safe from any intruders and I believe that this blog gave the best explanation and information about it.

https://www.idexcel.com/blog/tag/security-testing/

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

Behavior-Driven Development (BDD)

Behavior Driven development is an approach where the focus is set on the behavior of an application for the purposes of a business. This focus is to find a common ground between developers, quality assurance teams, and business professionals. Common ground is found by defining behaviors that are written in plain language, allowing everyone to understand and agree upon the software’s behavior.

BDD Process

Behavior driven development begins with defining behaviors in “feature files” which are used throughout the development process. Behaviors are straightforward statements that outline a specific process in a predetermined format.

Behaviors are written in a language called Gherkin, which use simple words such as “Given”, “When”, and “Then.” An example behavior would be, “Given the user enters an incorrect password, When they click the login button, Then they should be prompted with an error to reenter their password.” These behaviors are turned into tests with tools that check if the software behaves as intended. Because everyone is involved in this process, and agrees on the final product, confusion can be avoided.

Advantages to BDD

Behavior driven development leads to advantages that would otherwise be lost with other development approaches. A key advantage with BDD is better communication and collaboration. This is due to the nature of BDD as everyone from business, to quality assurance, to developers, meet together and plan everything. Because there is better communication, requirement understanding also increases. This is because requirements are explicitly defined, and everyone agrees what should be done. Due to the increase in requirement understanding, testers are made aware exactly what requirements should be tested. Ultimately the chances for the final product to be different than what was intended is less, saving time and effort.

Disadvantages to BDD

Because BDD is different from other development approaches, adopting the practice can be difficult. This is because teams are used to working amongst themselves, then meeting with the other teams once a final product, or an iteration of the final product has been completed. Waiting until a product has finished development before meeting the other teams can lead to wasted time and effort because what is actually delivered may be different than what the business team intended. Another reason why BDD can be hard to get used to is the overemphasis and learning curve with the tools necessary for BDD. Teams can get off track because they get caught up in learning Gherkin syntax and other tools.

Conclusion

This article was chosen because topics were easy to understand with the use of real world examples. Once past the learning curve, behavior driven development seems like a useful approach that fosters strong collaboration and communication. I was unaware of tools like Gherkin and Cucumber that are used to process the feature files, so learning about them was interesting. This approach is unlike others I have seen in the past; however, I am curious about how is all works. I will be looking into these tools in the future.

Resources:

https://www.browserstack.com/guide/what-is-bdd

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 this blog post, I want to talk about the “Record What You Learn” pattern from the “Apprenticeship Patterns” textbook by David H. Hoover and Adewale Oshineye. The premise presented in the pattern’s introduction,

“You learn the same lessons again and again. They never seem to stick… You remember doing very similar things in the past, but the exact details escape you.”

, captures some of the feelings that I’ve been having as our development group continues our work on Thea’s Pantry. I remember doing so much backend HTTP server work last semester, but I haven’t retained the lessons as well as I wanted to, and I feel like I’m repeatedly reviewing old material.

Lately, I’ve been reflecting on how well I’ve been nourishing my writing abilities – I stopped keeping a daily journal some time ago, and I’ve noticed that I haven’t been taking as many handwritten notes in my classes as I used to. The first reason I can think of for not wanting to stick to the habit is that I haven’t been exactly clicking with the record-keeping tools that I’ve been using. At first, I wanted to keep digital personal journals with tools like Microsoft Word or a journaling app on my Android device because I liked the idea of having as much space to write as much I wanted, without having to think about reaching a physical “end of the book”. However, I’ve realized over time that there are parts of the electronic writing process, like the glow of the monitor and the distractions of other applications, that can make it harder to concentrate on personal writing as opposed to pen and paper.

I’ve also been reflecting on my writing practices in addition to the tools I’ve been using. I’ve known for some time that I would be helped by keeping records of the things I’ve learned about computers, networking, and software development in my own writing, but I just haven’t known how to start or structure a collection of notes that I want to return to and reference in the future. One solution offered by the “Record What You Learn” pattern is to utilize a personal wiki to organize and store your notes. While I’ve been thinking I want to return to pen and paper for more personal writing, I think that a digital tool like a wiki would be a great choice to organize knowledge-based writing and references to further learning resources. The review process is also an essential part of using the “Record What You Learn” pattern. The authors emphasize the importance of rereading your material: “Your notebook, blog, or wiki should be a nursery, not a graveyard—lessons should be born from this record, rather than going there to die.”

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

The last few weeks of class have all been about Test Driven Development. Test Driven Development is when you use tests in order to guide you into developing software. According to a website called martinfowler, there are three main steps that we follow repeatedly. Those steps are:

1. “Write a test for the next bit of functionality you want to add.
2. Write the functional code until the test passes.
3. Refactor both new and old code to make it well structured.”

Essentially what this means is you create a list of things that you want included in your test, then you create a test for just one of those items. Once you create the test, you implement the code in order to get the test to pass. Once it passes, then you move on to creating the next test and getting that test to pass. If it causes the previous test you fail, you refractor until all of the current tests pass, then you repeat until all of the items you need are done. I personally find writing the test first to be a lot easier than writing the code first. That way, while you’re creating the code, you have an example to look back at so you know exactly what you want it to do. On top of that, focusing on one part of the code at a time makes it a little easier to develop the code without making mistakes, as you aren’t focusing on the entire program at once, just one small part at a time. According to the article, this form of development has two main benefits. It says “Most obviously it’s a way to get SelfTestingCode, since we can only write some functional code in response to making a test pass. The second benefit is that thinking about the test first forces us to think about the interface to the code first. This focus on interface and how you use a class helps us separate interface from implementation, a key element of good design that many programmers struggle with.” I chose this article as my source because I thought it did it a really good job explaining what to do step by step so you don’t get confused. On top of that, it explains the benefits and consequences of this method and how to avoid/achieve them. This article helped me further understand Test Driven Development and why it is useful.

Source: https://martinfowler.com/bliki/TestDrivenDevelopment.html

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

Summary:

This pattern describes growing your skills by challenging yourself with any opportunity that is given to you. Whether it’s done through taking on bigger or more complex problems or working with larger teams, there is always something to learn by trying something new. This also means seeking out projects to work on to build a portfolio and expand your skills.

Reflection:

For someone who started programming java in 2007, my portfolio is pretty barren. This comes down to two factors. Lost old files, and failing to start new projects. This pattern is one that I can definitely relate to the problem of feeling like I have plateaued. My eyes are opened to the truth as I get more exposure to the world of software development. If I am going to gain new skills I need to actively seek projects that push the boundaries of what I already know. I have always wanted to develop an application, but without any clear idea of what kind of application I wanted to make. This has always paralyzed me from actually learning how to develop an application. There are two clear solutions I can think of right now based off of two other patterns I have written about in the past. Following the pattern of “Find Mentors,” I could have sought out the guidance of a mentor and asked for ideas for projects that would develop my skills. The second pattern of “Breakable Toys,” gives me the option of just making an application for the sake of having a tool I can use. Making a breakable toy for an application would be a great way for me to jump into the deep end as far as pushing my knowledge of software development.

The other part of challenging myself is working with larger teams. Up until last year all of the projects I have worked on have been solo. Last semester, where I was partnered with another classmate, was one of my first exposures to developing large projects with someone else, and the challenges that come with it. Teamwork is crucial as anywhere I go in my career I will be working on a team, so being able to work together and communicate are important skills to develop. And just like learning from actually developing code, these skills will be built by actually working in larger teams.

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

The blog post, “The 3 Biggest Software Testing Mistakes” from Daniel Knott focused on highlighting vital mistakes that software testing groups frequently come upon in their testing strategies. I chose this blog post because as we continue to learn different software testing strategies in class I think it was important to highlight some mistakes that could be made as a tester so we can avoid these in the future. 

 The first mistake that Knott highlighted was the mistake of not asking enough questions. When you are working as a tester your first job should be to ask as many questions during the development phase of the product as possible. This will allow you to verify that the product will work as intended for the customer. These questions should be highlighting product features, limitations, etc. The second mistake is trying to automate everything. Automation if done right can be very helpful however there are scenarios where automation can do more harm than good. Knott says that many teams mistakenly aim to automate everything, often driven by those unfamiliar with automation’s true benefits. Some parts of the code that are still in development, may not be ready for automation, while other areas will require detailed quality checks that automation cannot provide. Due to this, a risk assessment and informed questioning should precede test automation while working. Once suitable areas for automation are identified, decisions on the level of automated checks should be made by the team.The third mistake in software testing is reusing the same test data repeatedly. Software testing heavily relies on data such as text, images, or voice, and system configurations. Reusing test data compromises its integrity. The system’s state or configuration may change between tests which could affect results. To effectively test an application, the development team must define and generate appropriate test data. Generating test data can be complex, depending on the system’s intricacy and technologies involved. Ideally, scripts can create test data for specific tests, allowing for deletion or reset afterward. The conclusion of the blog post has Knott describing how mistakes can be good as they are a part of growing as a software tester. The best thing we can do is to be transparent about our mistakes to allow for a culture of learning.

After reading this blog post, I believe that I am now more confident and informed about how a software tester should go about testing strategies. Being able to identify common mistakes will be beneficial so I can avoid doing those mistakes in my own work. I found it interesting the fine line between automation since it can be both beneficial and harmful depending on just what you are working on. This is why as I read it is best to be left to a team decision as automation has its own list of pros and cons.

https://shiftsync.tricentis.com/testing-strategies-methodologies-42/the-3-biggest-software-testing-mistakes-95

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.