A Review of: You Still Don’t Know How to Do Unit Testing (and Your Secret is Safe with Me)

Erik Dietrich’s article “You Still Don’t Know How to Do Unit Testing (And Your Secret is Safe with Me) was an amusing and informative read about what Unit Testing is, what it is isn’t and how the average developer can go from creating incorrect tests to effective, bonafide Unit tests. He leads the article with a remark that, since 2002, he has seen unit testing go from an esoteric skill for quirky developers to something of an industry standard that, as it has been ushered in into popularity, has also pushed some developers into the cracks; this article is for them. Dietrich starts by making several important distinctions on what a unit test is not starting with tests that he describes as being able to “fail when run on a machine without the “proper setup”.” He next brings up a concept which I had not heard of before called “smoke testing” which seems to be testing cases that cover the most essential parts of a program to determine if it’s launch ready. Whatever the case, this is certainly not unit testing. Lastly Dietrich states that a unit test, under no circumstance, should be something that works your system from end to end. He gives the example of a user opening a terminal and testing output; he classifies this as an end-to-end test. In the author’s words the concept of Unit Testing is by most accounts circular but with some good reason (to transcend programming language). The example given was programming methods in C# and their respective test methods. The first example is testing with an “add” method from a calculator that checks to see if the arguments passed successfully add or, if they do not, that they properly throw an error; for this case it is the Invalid Operation Exception. For more practical detail check out the original article here.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows-Apprenticeship Pattern

In this post, I will be writing about the “Rubbing Elbows” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This pattern is for people who typically work alone when it comes to developing software and feel as if they had reached a plateau, not learning superior techniques and approaches.

The Rubbing Elbows apprenticeship pattern suggests that in order to cure this, you should work side-by-side with another software developer to complete hands on tasks. This can help you learn things that cannot be taught in a classroom or online. This is because you will pick up on certain micro-techniques that you can only really obtain through experience or being around/working with another developer. These techniques can add up, providing a significant increase to your skill. An example of this pattern given in this book is pair programming. When used correctly, it can be one of the best ways to learn. Pair programming (especially with a mentor) can help you pick up other skilled developers’ habits and lets you observe how they polish those habits to improve their own skill.

If you do not have this opportunity at your workplace, the book suggests that you find someone who is interested in contributing to open source projects. It suggests you should take one night a week to work with this individual on the project in a sort of pair programming manner, learning from each other as well as motivating each other.

I completely agree with what this pattern says. Working together with someone on a project or tasks, side-by-side, especially with someone with greater skill can greatly boost your skill, and exposes you to certain things that you cannot be taught directly. Not only with coding, but with other hobbies in my life, being around others really helped me pick up on things quicker. For example, I started snowboarding last year. I had three friends who I would primarily ride with, two extraordinarily better, and one the same skill level. I had been motivated by the one the same skill level, and learned from him by observing certain techniques and habits that helped him improve. I had also picked up certain styles, techniques and habits of the ones already at a high skill level, boosting my knowledge and understanding. Now a year after starting this new hobby, I am more skillful than 70% of people on the mountain(not to be smug). This is greatly because of going with my peers.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Scrum Quality Assurance

            Given that we are working in a Scrum team in our Software Development capstone and that we got ample practice with the Scrum in our Software Project Management course, I thought it would be interesting to see the crossover between quality assurance and the Scrum workflow. Scrum is also widely used, so this should be important to know for the future as well. I found this article: https://medium.com/serious-scrum/how-does-qa-fit-with-scrum-4a92f86bec5b which talks about the role of quality assurance on a Scrum team.

            It’s important to remember that the members of a development team do not have pre-defined roles. It’s assumed each member of the team can collaborate with any part of a project, even if certain members have more specialization in certain areas, like product testing in this case. With that in mind, it makes the Definition of Done all the more important. Requirements for testing should be documented and understood by the development team and the product owner. This prevents conflicts during the sprint review if the development team thinks something like compatibility testing needs more work and the product owner is ready to deploy. If there is a more comprehensive Definition of Done, these conflicts are avoided since they would have been discussed ahead of time.

            Quality assurance on a Scrum team is a large part of the process and requirements are developed during sprint planning. It’s important that there is close collaboration during the sprint between the development team and the product owner though, even though the development team is delegated most of the decision-making responsibility for how work will be completed. This keeps the whole team in tune and avoids conflict. It also provides for a closer, more efficient work environment as understanding is enhanced throughout the team and the owner.

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

Sprint 1: Retrospective

If anything can be said about this sprint, it is that a lot was learned throughout. I was familiar with how the teams would work, but many of the day-to-day specifics and exact deliverables were a bit unclear to me. Before this class I had only really examined this sort of team structure in CS-348, and that more theoretical practice left me in the dark on some of the specific aspects. To specify, the issue board for our team was not utilized to its full potential in a few different ways. However despite these issues we were able to complete all issues on the board. First I will discuss exactly what worked well, and subsequently what did not.

Regardless of what could have been improved, which will be discussed, this was overall a successful sprint. Each team member did, at the minimum, read through the material they were assigned and documented any relevant information in the wiki. So by definition this was a successful sprint, but it’s true value for us was what we learned for the next sprint in my opinion. One part that could have been worked on were the actual issues themselves. These could have been streamlined a bit, as we simply decided to read through all of the documentation because it was the most logical thing to do. However the documentation often contained much superfluous information that may not really end up  being useful. It felt as though this was mostly being done to meet our SCRUM goals. Besides this, it was still difficult to communicate all of this information with each other. Throughout the sprint we also forgot to move issues through the board as we worked on them, and I personally did extraneous work that could have qualified as a new issue but did not think to create one for them. After all of these issues however, there are some changes that can be made for this next sprint.

This first sprint was an extremely valuable learning experience as previously stated. There are a few ways that our community of practice could improve the effectiveness of our teamwork. One idea that was brought up was to simply communicate more often using the community of practice channels. This will allow us to simply have one location containing all information we may need, and allow us to be on a similar page with each other. To further improve this, we also discussed having small work sessions in the community of practice from time to time to ensure none in the group are behind. This would also allow us to have more consistency in the method that we use to connect our respective systems to Keycloak further down the line. As for myself personally, my major flaw was simply getting behind on my work. If I am being honest, I had to do much more reading towards the end of the sprint than should have been necessary. To improve on this, I have set aside specific time frames during the week to work on projects. I will also try to share any more useful information in the project-wide community of practice, as I have a tendency to just share information in my team’s text channel only. I am excited to put all of the changes into play for this next sprint!

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Software Testing Life Cycle

            I was interested in learning more about how software testing works in the professional world on a software development team. Since we are learning about the crafting of software tests in our class, I thought it would be interesting to learn how the pieces are put together, like how developing requirements goes into crafting tests and then executing them. It’s an essential part of a software development team, of course, and I’m sure I’ll be doing plenty of it in my future. I found this resource: https://www.tutorialspoint.com/stlc/stlc_overview.htm from Tutorials Point that gave an overview of the “Software Testing Life Cycle” (STLC) which help put the pieces together for me.

            First, what is the STLC? It deals strictly with testing and “starts as soon as requirements are defined… by stakeholders.” Sidenote, this reminds me of test-driven development, which, by my understanding, is a common practice in software development these days. The STLC consists of 7 parts. The first is requirement analysis, at which point the team analyzes the application under test (AUT) at a high level. Then comes test planning where a strategy for testing is devised. Then is test case designing which is applying the requirements and making tests according to the planning. Then is the test environment setup for integrated testing. This is the last step before actual testing. Next is test execution which yields defect reporting. This either validates tests or finds bugs. Last is test closure, where testing is finished and matrix, reports, and results are completed.

            This was great to see the pieces come together. This very basic overview helps me see what working on software testing in the professional world would be like. Seeing a timeline also provides context for some of the things we’ve been learning in class.

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

Boundary Value Analysis and Equivalence Partitioning Testing

When it comes to a large pool of input data, it is not possible to perform exhausting testing for each set of test data. There should be an easy way to select test cases from the pool so that all scenarios are covered. This is when the Equivalence Partitioning & Boundary Value Analysis testing techniques were introduced. In today’s blog, I want to do further research on the testing technique of Boundary Value Analysis and Equivalence Partitioning Testing. Equivalence Partitioning and Boundary value analysis are linked to each other and can be used together at all levels of software testing. To start, Boundary value testing is the process of testing between extreme boundaries between the partitions, for example like start, end, lower, upper, maximum, minimum, just inside, and outside values. Normally Boundary value analysis is part of stress and negative testing. Using the Boundary Value Analysis technique tester creates test cases for the required input field.

Now when it comes to equivalence partitioning or equivalence class testing is a type of black box testing technique in which the input data units are divided into equivalent partitions that can be used to derive test cases. This helps with reducing the time required for testing a small number of test cases. This technique can be applied to all levels of software testing like system, unit, and integration. One of the examples that were widely used in many resources that I have look at is: let us say a password field accepts a minimum of 6 characters and a maximum of 10 characters, that means results for values in partitions 0-5, 6-10, 11-14 should be equivalent.  The three testing scenarios will be:

1       Enter 0 to 5 characters         System should not accept

2       Enter 6 to 10 characters       System should accept

3       Enter 11-to-14-character      System should not accept.

Equally, Both testing techniques are used to reduce a very large number of test cases to a manageable piece, Both are appropriate for calculating intensive applications with such a large number of variables and input data.

https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html

https://www.softwaretestingclass.com/boundary-value-analysis-and-equivalence-class-partitioning-with-simple-example/

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Find Mentors

            The “Find Mentors” learning pattern from the Apprenticeship Patterns book is one that I definitely should have focused on earlier. This pattern is focused on find more experienced developers around you early and leveraging their knowledge and practice to take steps forward in your apprenticeship. Keeping with the master craftsman and apprentice theme, no apprentice will learn as effectively without someone to help them along their way and point out the unknown unknowns. The pattern recommends reaching out early and often. The only downside is rejection, which is easy to get over, especially if it is followed by acceptance at some point.

            In my computer science journey, I need to take this message to heart. Oftentimes, I try to do most of my learning on my own. I know I can have a kind of unorthodox way of teaching myself things, so I usually try to stick to myself when learning. I do quite often leverage the help/advice of peers though. Most of the people I’ve become closer with in the WSU computer science program I have worked closely with and either have some knowledge to gain from them or have some to share. While I realize working with peers is great, I definitely have fallen short on the front of getting help from those who are leagues ahead of me, like my professors. Looking back, I definitely should have attended more office hours and been in closer contact with my professors and advisors. That’s a goal I have for grad school, especially since I hope to be working as a research assistant, so this would be perfect.

            As the pattern mentions, it is difficult to get over the awkwardness of asking someone to mentor you. I’m not really sure how or who to reach out to in a professional setting, and I’m also not sure of what I would be looking for from a mentor. Although mentoring in school is great, it would probably be quite different than mentoring in a workplace. This is something I should look further into. Who can I reach out to as a mentor and what should I be looking to gain from them? If I can get the answers to questions like these, I think I would feel more comfortable filling the apprentice role.

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

The Power of Decision Table Testing

In POGIL activity 8, we worked with decision table-based testing and applied it to applied this concept to the ongoing graduation problem. Unlike the previous activities, we did not go over the advantages of using a decision table opposed to using any of the other testing frameworks. So for this blog post, I want to look more at the pros of using decision table-based testing.

In this article, it gives a complete step-by-step rundown of what is a decision table, why we use it for testing and how to conduct decision table-based tests.

A guide to Using Decision Tables

It is basically a review of what we covered in class with pictures/diagrams at each step.

In this second article, it talks about the characteristics of decision tables and why some of these characteristics may make decision table-based testing more preferable to the other testing frameworks.

https://www.edureka.co/blog/decision-table-in-software-testing/#advantages

Decision table-based testing is similar to Equivalence Class testing in the sense that it divides the tests into cases and complete test coverage. Unlike Equivalence Class testing, decision tables are more versatile. One aspect that I really liked about this second article was the fact the author completed multiple action rows into just one rule by defining a key. This made the table smaller and easier to read while not obscuring the meaning within the table.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

The Long Road – Apprenticeship Pattern

What this apprenticeship patter talks about is that this journey of a software developer and that of a software craftsmen is all about the long- term. You have to have the long-term mindset and vision to always be learning and realize that you will never be done. People now a days are looking for ways to quickly do everything and have the ability to do something overnight. Well, when it comes to software development and the journey that needs to be followed, this won’t be realistic. In order to build the skill of the best software developer, you need to realize that this will take time and years of practice and learning. I think this is a good mindset to have in order to not give up and keep on pushing yourself when times get tough. One thing that I have seen over the years with coding is that when people start to have a tough time with it and can’t seem to figure something out, they give up and self-declare that programming isn’t for them. They didn’t even realize that with just a little bit more effort and time they would have figured and become better coders, while also increasing their confidence. This shows to me that no matter what adversity you face, that you need to keep on going and not give up at a time where you need to put in the most effort. Once you past that barrier, the road just starts to get a little bit easier and you will become more capable of dealing with problems, that just a while back you thought was impossible.

Taking the long road is a key in the software world and is also a key in our everyday life. I’m sure there were times when we did not want to do something and thought of something as hard, but looking back at it seems silly to us. This is why when you keep a long-term vision, the issues that come in the present time won’t seem so big because you know at the end it will all be worth it. The software craftsman is striving to keep on improving and learning because they know it will all be worth it and the journey will be a great one. Overall, the message is to keep on striving to learn and build up skills and work hard to break through barriers by not giving up.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Concrete Skills

This week I chose to look at the “Concrete Skills” pattern. This pattern explains that you need concrete skills to be able to get a job and contribute to the team you are joining. Concrete skills mean discrete abilities you can demonstrate using specific technologies. Something like understanding and being able to apply a certain framework or being able to write docker compose files. Things beyond soft skills like being able to learn quickly and having a good attitude. Creating a toy project can help show your concrete skills to employers and comparing your CV to the CVs of people whose skills you respect can help you take stock of where your own abilities stand.

I found this pattern interesting because it is a very helpful thing to think about when writing a resume or CV. Especially in a technical field like software development, you need to have very specific skills to be able to do the job you are hired for. Thinking about what concrete skills you have and making those specifics clear can really help you when looking for a job and it is definitely something I will be thinking about as I enter the workforce.

I also found it interesting when the author wrote about “buzzword bingo”. If you do a quick search for software development jobs, you do see a lot of these buzzwords and that can sometimes be really intimidating. Having ultra-high standards for software developers in kind of a meme now too (10+ years of experience in Swift required!!!). Making a list of these concrete skills helps make that a little less intimidating as you realize how capable you really are. That or it can help you see how far you need to go. Taking stock of your abilities is a good thing.

I know I am lacking a bit in the concrete skill area. A lot of the work we are doing with the project this semester will help fix that deficiency. We are working with so many new tools and I feel like I am learning more about software development than ever before. Putting myself in the uncomfortable position of creating something complex using brand new languages and technologies is pushing me towards becoming a better programmer.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.