For our final assignment for the course, we are being tasked to create a sort of activity similar to the activities we have been doing in class this semester for my software testing course. In working on this activity, we chose to write an assignment based on behavior driven development, using the Cucumber tool. As such, before we really get into the weeds of the assignment, I thought it would be a good idea to look into the tool myself and what behavior driven development looks like.

For today’s post, I’m looking at a blog post from Moisés Macero on The Practical Developer blog.

Firstly, behavior driven development is built for fostering communication and discussion around systems and how they should properly be working. Typically, the process is in three stages: discuss, capture, and write tests. We want to talk about what the requirements really should be between the product owner and developers, refine what our requirements and targets should be, then move forward to building the software and testing it.

What Cucumber does for this is introducing syntax, called Gherkin, to enhance the readability of tests even for people who don’t know how to read code. The syntax is styled in a format of ‘given’, ‘when’, ‘then’. You mark these test cases with keywords such as feature, scenario or example to accurately describe what the code should be doing and how it is being tested. One of the examples used in the article is the following:

  Scenario: Users solve challenges, they get feedback and their stats.
    Given a new user John
    When he requests a new challenge
    And he sends the correct challenge solution
    Then his stats include 1 correct attempt

Here, you can see that the syntax is (probably) easily readable and understandable even if you don’t have any software development experience. These statements are stored in .feature files, and act as sorts of definitions for tests.

For the actual testing, you apply these definitions by writing Cucumber expressions in a step definitions file. These are essentially files that not only test the code in a step-by-step approach, but also features readable headers for each function. Here’s an example of a couple of functions using Cucumber expressions (taken from this post in the same series):

    @Given("a new user {word} is created")
    public void aNewUser(String user) {
        this.challengeActor = new Challenge(user);
    }

    @When("they request a new challenge")
    public void userRequestsANewChallenge() throws Exception {
        this.challengeActor.askForChallenge();
    }

    @Then("they gets a mid-complexity multiplication to solve")
    public void getsAMidComplexityMultiplicationToSolve() {
        assertThat(this.challengeActor.getCurrentChallenge().getFactorA())
                .isBetween(9, 100);
        assertThat(this.challengeActor.getCurrentChallenge().getFactorB())
                .isBetween(9, 100);
    }

Cucumber supports a variety of different languages, and also supports testing frameworks such as JUnit, which means it is also very versatile and can be used alongside a testing driven development environment as well.

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

During this semester we have learned about many different testing techniques, some being a lot easier than others. One of the testing techniques that we have learned is called Stochastic Testing. Stochastic testing is a type of black box testing method in which random tests are conducted over time. These tests are performed by automated testing tools in order to see if the software can pass a large number of individual tests.

Another type of testing technique that we have talked about is Property-based Testing. Property-based Testing is very similar to Stochastic testing. In this testing technique, the testing is also automated. However, it isn’t just executing the tests that is automated, it is also generating the tests. While researching the topic, I came across an article called “What is Property-based Testing?” by Alex Robert. In this article, Robert states “Property-based testing automates that work for us. Test automation allows us to generate better tests with less work and less code, so that we can focus our effort on the less mechanical work developers excel at. Instead of writing tests with manually created examples, a property-based test defines the types of inputs it needs. In the example above with CommonPrefix, the input would be two strings. The property-based test framework will generate hundreds if not thousands of examples and feed them to your test function.” He talks about how property-based testing can create a ton of different examples for your test function in order to help you test your program.

In this article, Robert also talks about input generators and what they do. A generator is a function that returns an instance of a given type from a source of randomness. These generators are great for randomly creating new inputs for the test function. However, they are only efficient if the generators have a good framework in order to help uncover more issues with the code. Robert gives a list of qualities that he thinks would make a good generator. His qualities include: a generator should be fast, a generator should be deterministic, a generator should not waste randomness, and a generator should cover the code under test. Most of these property-based testing frameworks come with a built-in generator which can be extremely helpful for testers, depending on the type input parameter. I really enjoyed reading this article as looking at all of the examples given by Robert helped my understanding of the topic. I know that if I ever need to use this type of testing technique, I will definitely use this article as a reference.

Link: https://www.mayhem.security/blog/what-is-property-based-testing

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.

The blog post, “Unit Testing Best Practices: 9 to Ensure You Do It Right” focused on highlighting important habits and practices that testers must utilize to increase efficiency and effectiveness. 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 important aspects that could be utilized as a tester so we can make sure we incorporate these in the future. I thought that this blog highlighted good practices that were covered in class and even added some more.

The blog presented recommendations and strategies for effective unit testing, catering to developers aiming to streamline their testing workflows.The blog begins by explaining the significance of unit testing in software development, highlighting its role in detecting bugs early, ensuring code reliability, and facilitating code maintainability. It emphasizes the importance of adopting a systematic approach to unit testing to maximize its benefits. The blog advocated for writing clear, concise, and focused tests that target specific functionalities or units of code. Emphasizing readability and maintainability, the blog suggests using descriptive test names and organizing tests into logical groups. The blog also addresses the importance of test automation in modern software development. It advocates for automating unit tests to expedite the testing process and ensure consistent test coverage across code bases. By integrating automated tests into continuous integration pipelines, developers can detect regressions early and maintain code quality throughout the development lifecycle.In addition to automation, the blog stresses the significance of test isolation and dependency management in unit testing. Techniques such as, mocking and dependency injection are recommended to isolate units under test from external dependencies. The blog also touches upon strategies for handling test data effectively, including techniques like parameterized tests and test data factories. By managing test data efficiently, developers can enhance test coverage and minimize test redundancy.

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 know good testing practices will be beneficial so I can focus on utilizing the skills within my own work. I found it interesting how most of the practices that were being mentioned in the blog were very simple. This makes it even easier to understand and incorporate these rules as they will be easy to remember and become a standard foundation whenever I have to think about writing tests for a project. 

https://www.testim.io/blog/unit-testing-best-practices

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.

With software development, working in teams is typically normal. Being able to work in a team is important. But what is also equally important is interacting with stakeholders. A team does not make a project just because, typically someone comes up to the team and gives an idea and the team gets to work. That is an extremely watered down version of how it happens, but that is how it works. This can be somewhat confusing so let’s break it down. 

In this blog post, they talk about what a stakeholder is, why they are important and then some examples of a stakeholder. The post defines a stakeholder as a group of people or groups affected by a software development project. They are in the best position to offer specific input on needs at their level. Essentially, they are people who know what they want for this project and those whose interests are important for the project. It is important to get their input on the project because they guide the project in a way. They are able to create a list of things that are needed for the project and a way for the developers to figure out what they are working on exactly. You do not want to ignore the advice of stakeholders and neglect them, as that means the developers are just making the wrong thing. But who is considered a stakeholder? End-users are good to consider, as they are the ones to be using it once it is complete. Knowing their input and how it affects them is important. People like managers, project managers, developers, and partners are all important, as they ensure that certain aspects of the project are doable. Certain authorities are also important to consider, such as shareholders or company owners. It is hard to get everyone in for a meeting on the project all at once, so getting representatives is a better alternative. Determining whether or not their input is needed is also important, as to not waste someone’s time. But again, how do you determine that? There are some questions you can ask, such as “who will be affected by this product,” “how will workflows change,” and “are there any people whose support is vital to the project.” 

Understanding who has valuable input and is able to shape the project will be key to you as a developer, as it lays the foundation and blueprint for what you and your team will be doing. It may be difficult to get everything everyone wants, and you may have to cut some things. But knowing when to do so is up to you and the team.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I have found an article about encapsulation. Encapsulation is more than defining accessor and mutator methods. It also follows two main objectives hiding complexity and hiding the sources of change. To understand more about encapsulation, we will first need to understand the two concepts of modularity and abstraction. In the article, Edwin Dalorzo, the author of the article, uses the example of a car to understand abstraction. He says on this, “A car is complex in its internal working. They have several subsystems, like the transmission system, the break system, the fuel system, etc. However, we have simplified its abstraction, … we know that all cars have a steering wheel through which we control direction, they have a pedal that when we press it we accelerate the car and control speed, … These features constitute the public interface of the car abstraction” (Edwin Dalorzo). This is a great example because we can use abstraction to simplify unnecessary parts that the users would not need to understand. This concept is similar to modularity. In his book Code Complete, Steve McConnell said on complexity “ the interface should reveal as little possible about its inner workings”. So now that we understand the two concepts, the idea of encapsulation starts to unravel.

One of the things that we want to always encapsulate in Java is the state of a class. This should only be accessed through its public interface. Edwin says on encapsulation in Java, “In a object-oriented programming language like Java, we achieve encapsulation by hiding details using the accessibility modifiers … With these levels of accessibility we control the level of encapsulation, the less restrictive the level, the more expensive change is when it happens and the more coupled the class is with other dependent classes (i.e. user classes, subclasses, etc.).” (Edwin Dalorzo).  It is crucial that we keep this idea in mind while we design encapsulation for these public interfaces so that we can foster evolution of our APIs.

As talked about in the article, it is often wondered why we need to use accessor and mutator methods in Java, aka getters and setters. With encapsulation in mind, it is not there to hide the data itself but the implementation details on how the data is being manipulated. So once again we would need a public interface to gain access to this data. However, by exposing this data we risk losing encapsulation. So this is why we would need to encapsulate this information.

https://dzone.com/articles/why-encapsulation-matters

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Until I can obtain a job, I will be working by myself most the time. This will inevitably impact my learning because working with others allows shared knowledge and experience for the parties to teach each other. The “Rubbing Elbows” pattern from Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman discusses the benefits of collaborating with others.

The pattern mentions “Pair Programming,” a technique where developers code side-by-side. I have not coded in this manner in a long time. When I took my first computer programming class my best friend and college roommate was also taking that class. Given the circumstances, we often collaborated on assignments. While we did collaborate, we often coded the assignments solo and discussed our methods and problems. I cannot count the times that one of us would get stuck with an issue that the other had no problem with. I learned then that different programmers will find multiple solutions and methods while developing. These diverse techniques are worth examining and potentially adopting.

“Pair Programming” is not the only way to practice “Rubbing Elbows.”

“The goal is to find ways to expose yourself to the daily working habits of other skilled people, and observe the ways in which they gradually refine those habits into even greater skill. These habits extend beyond coding and into all aspects of software development.”

This statement from the pattern shows the type of knowledge the pattern will provide. “Rubbing Elbows” is not necessarily about learning new coding methods but about observing the small, often unmentioned details of a developer’s work habits. Because of this, developers can rub elbows by working on any part of the development process, including presentations or papers.

Working in LFP’s update module team provided plenty of learning opportunities for me. Some opportunities were coding related, while others were about project management.

I have a couple ways planned for practicing this pattern. Now that I am graduating, I think this would be a great time to collaborate on a project with my friend again. We have not worked together in years and this seems like an opportune time. He has been working in development for awhile and I am sure he has a lot for me to learn. I also plan on participating in the LFP spike-a-thon this summer. This will let me work on something familiar while presenting opportunities to work with other developers.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

I will hopefully be starting my software development career soon, and with that I will be joining a new team. Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman’s pattern “Sweep the Floor” suggests “volunteer[ing] for simple, unglamorous, yet necessary, tasks” to contribute to the team. I will be one of the least experienced members in the team, so I’ll need to be proactive working on the more tedious work. Doing these tasks is more than just gaining trust from the team but also showing respect for the more experienced members. The experienced members should be focused on the work that requires their experience and not bogged down by simple chores.

“Examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.”

While it may not be fun work, these tasks are still important, and the team will be grateful for the effort. To practice this pattern, “Sweep the Floor” suggests finding the tasks that the team has been putting off and do them. The pattern however warns of the potentiality of being perceived as incapable of more vital work. This can be averted by working on more complicated issues or personal projects alongside the simple chores.

When reading through the list of example tasks, I could see the tasks that often held up work during our LFP sprints with code review being the biggest culprit. I can see how completing these tasks would be good to focus on when joining a new team. Not only will the team benefit from these tasks being done but completing these tasks will also give valuable insight into the project. With code reviewing, the opportunity to study the unfamiliar parts of a project is presented. Work on the documentation was also often put off or forgotten.

I think this pattern makes sense having the inexperienced members handling the simpler tasks. These tasks are chores to the experienced members of the team but are learning experiences for the inexperienced.

The pattern includes an experience of a developer working in a formal software apprenticeship. The important part of the story is when the apprentice watches Uncle Bob Martin, a master craftsman, take out the trash. The apprentice’s mentor then scolds the apprentice for allowing the job to go undone and having a master craftsman take care of it.

“It is not the job of the master craftsman to take out the garbage.”

This pattern has made clear what I will need to focus on when entering a new team as an inexperienced developer. I will need to find the simple, more tedious jobs and work on them while furthering my learning. “Sweep[ing] the Floor” will help with my integration into a team by familiarizing myself with the code base and team practices. I will also build trust with the other members of the team. Once I gain enough experience and trust, I can then start to work with more complex, interesting work.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.