Unit Testing: What Types to Use

Now that we have a good base understanding of unit tests we can dive a little deeper into the subject. When reading through the previous blog I saw mentions of different types of unit tests and my interest was piqued. From past examples I had seen, I assumed all of these tests followed the same format. Thus for this week’s post I wanted to discuss the different types of unit tests, as I only just learned that there were multiple. To aid in this I found a blog post from a programmer named Jonathan Turner who clarifies what each type is.

This blog post identifies three major types of unit tests, these being arrange-act-assert, one act, many assertions and finally test cases. The arrange-act-assert format is the more traditional method of unit testing and the one that most people are probably familiar with. This format involves setting up the conditions for the test, running the code with the test conditions, and subsequently examining the results of the test. As for the one act, many assertions pattern it uses the same basic setup as the previous pattern, but differs in having multiple assertions about the code at the end of the test. Finally there is the test cases patterns, which takes a different approach than the other two by using a collection of many inputs to check their respective outputs. Now that we understand what each of these patterns are we can discuss their advantages.

Each of these tests have their own use cases where they will be most efficient. The arrange-act-assert pattern is the traditional method and, thus, the most straightforward to implement. This pattern should mostly be used for testing specific conditions or situations of a certain system. The one act, many assertions pattern is best used when you have code that has different sections that each act independent of each other. To clarify, use this if testing a method that has multiple blocks of code that do not affect each other, but must each be validated. Finally, the test cases method is very advantageous if you have a program that has a wide span of input output values. This could be one implementing an algorithm that converts values; the blog post gives a very good example. I hope that this post gave you a glimpse into the variety of unit tests available and would recommend checking out the blog post by Jonathan Turner for further information.

Source:

https://www.pluralsight.com/tech-blog/different-types-of-unit-tests/

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.

Sprint 1 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project

This is our example repository that contains everything we worked on for Sprint 1.

Review Docker: Reviewed old projects and main commands for docker.

Create Sample Docker projects: Created a sample Docker Project, Did the getting started activities.

Repository for event project: The main repository for the event project.

Learn About RabbitMQ : Learned RabbitMQ components and Implemented them using Docker.

Review Scrum :  Reviewed the scrum guide and understand the process.

For the project, I am part of the reporting team. I mainly work on the event system software that sends and receives a message to other systems using the RabbitMQ messaging system interface. I also work with the database person and did make a docker example project and a cheat sheet of all the docker commands.

What worked well / did not work well

 The thing that worked well for our group is that we were good at organizing everything and everyone was responsible for certain tasks, and I noticed that some of the tasks overlap between us. For example, the backend person must work more closely with the database person. The first few days we were a little confused, but as everything came together our workflow improved tremendously, which helped to complete all the issues for sprint 1. One thing that did not work well is that we had few problems with GitLab, our template was not loading properly at the start so we could not assign proper labels to issues. Also, during meetings, we should have done the group tasks together instead of a person just doing the task.

What changes could be made to improve as a team?

For a project, communication is the key to success. I think that as a team we should be communicating more rather than doing our tasks during the meetings. For instance, if someone is struggling to figure something out, the other team members can help the person and give insights to lead the individual in the right direction. Also, for the next sprint when we are making cards we should be more specific about the descriptions and properly think about the issue and how we can achieve it and it is clear to the person what needs to be done.  

 What changes could be made to improve as an Individual.

As an Individual, the change that I can make is to plan properly for the next sprint. The first sprint I started of slow because I was not sure how you do something or if I am doing it the right way. A properly planned sprint will help me to go with a flow and have a balance rather than getting overwhelmed by doing all the tasks towards the end of the sprint. My communication with the team should get better as we move on to the next phase.

Overall, this was a great learning experience. I think the first sprint was a success and a starting point for our team to move forward with a vision to complete the task that is assigned for us. I’m looking forward to working with the other teams to combine everything and see our progress.

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

Software Quality Assurance and Testing Blog Post #3 (Black-Box vs. Gray-Box vs. White/Clear-Box Testing)

On the first exam for my Software Quality Assurance and Testing course, and in activities previous to it, Black-Box, Gray-Box, and White/Clear-Box Testing were important topics/definitions to thoroughly understand. Not only did we have to know the meanings of these terms, but we had to be able to compare them and know how those testing methods are used. White/Clear-Box Testing is when the tester knows the contents of a function or method. This comes with its advantages and disadvantages of course. The advantages are that it is very easy to navigate the complexity, get legible test cases, and makes debugging smoother. The disadvantages would include bias being used by the tester and possibly longer and more expensive testing in general. On the other hand, Black Box testing is quite the opposite. The tester is not able to view the inner workings of the function/method and is only able to test based on what inputs are given and what outputs are received. Although this seems counterintuitive for a testing method, it also has advantages and disadvantages that make it a viable option. The advantages would be that it would take less time and expenses to test and that it eliminates tester bias altogether. The disadvantages are that because the tester is not able to see the inner workings of the function or method, it makes it harder to debug, find complexity, and have easy to read test cases. The two methods are basically opposites. Lastly, Gray-Box Testing is somewhere in-between the two. The tester knows a little bit about the inner workings of methods and functions, but is not focused on them completely like in White/Clear-Box Testing. This makes all of the advantages and disadvantages even out more overall which could be good in some cases but could also not be a valid testing option in other cases. Before this semester, I actually had never even heard of these terms, and it was interesting to go through and research them for this post and for my course!

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog Post #7

For my second to last apprenticeship pattern blog post review, I would like to talk about simply because of how close it hits to home with me is the pattern entitled “Draw Your Own Map” in the textbook readings. This pattern is based on the fact that throughout the lives of software developers, there will be many times in which jobs or opportunities will not quite fit what they are capable of or are even interested in doing. The main issue brought up in this chapter was that none of the career paths provided to young software developers are often fitting for them. The reason that I chose to review this specific pattern is because I believe it relates to me very deeply as I am worried that whatever direction I end up taking after college may not be right for me. I already have many different options and directions that I could take from here and the opportunities are almost more daunting than exciting at this point. I am worried I will make the wrong choice early on. The book tried to solve this problem by basically saying that I choose my own destiny. “Identify a logical but ambitious next step for your career. Understand that it’s not up to your employer, your career counselor, or your professors to give you a hand up.” Sometimes the guidance of others is not what is needed even if it is with good intentions, because more often than not, I should know what I like best. The book also explains that no matter what direction I want to choose, it is important for me to make sure to take the first step. Without the first step, the dominos will not start falling and there will be no momentum toward my goals. If others (such as employers) try choosing a path that is not right for me, I must reflect and make the decision to stay on the course that I personally see best fitting for me. Obviously, when working, I should complete my roles and not give up, but in the end, it is not wrong for me to change direction and even switch career opportunities for my own betterment if I feel I need to.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog

Links:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/2

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/19

I worked on reviewing docker and creating a sample docker project with the links above. These were both team issues that we all worked on.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/10

I used tutorials online and several websites to review details about mongoDB.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/17

I created a sample mongoDB project for practice and getting familiarized with the database.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/9

This was for creating the main repository for the database that we will be using in reporting system.

The thing that worked well in this sprint for the group I was apart of, the reporting system, was that we organized each step of the way and tried to breakdown things to be more manageable. Each individual was responsible for certain tasks, such as in my scenario I was focusing on learning about the database aspect. Also, we had other issues assigned that were team based and so each individual in the group would work on that because it would be important for the whole team to learn about that specific issue. Overall, the planning at the beginning of the sprint helped keep the tasks we had to work on as a group clear, which led to us completing all the issues we assigned to ourselves.

Some things that didn’t work well was that we had problems in the beginning creating templates to explain what each issue was for on the cards. I think our group knew what we were supposed to do and communicated via discord, but didn’t put all the details we could have on the cards. Also, I think that when we have meetings we should focus on what we can do as a group that day and then on our own time work on the individual tasks.

Some changes we could have made as a team for future sprints are creating cards that aren’t so broad and keeping the issues more clear. Although it was the first sprint and there was a lot of learning to do, I believe that in the future when more implementations and detail will need to be done then it is important for us to break down the issues so they are representative of their point total. We can’t just put an issue and keep it so vague that once the sprint starts, it turns out the issue is a lot more complex than anticipated. Therefore, in the future as a group we can ask more questions for each issue assigned and say whether this will be enough of a task and whether the requirements are clear for the person to work on.

Changes I can make as an individual to improve the sprint is to start balancing out the work from the beginning of the sprint to the end. I feel like for the first sprint, I started off slow, in terms with how much work I got done, but towards the second half of the spring is where I completed most of the work. I think if I keep an equal balance and more momentum from the start, it will be a lot easier to manage and help myself as well as others to not be overwhelmed.

Overall, I think the first sprint was a success and it was really helpful working with a team on a project and deciding how we will break it down. I think when there is a full team working on creating something big, then each individual has ideas that we can use to help each other and be more creative in the process. The more ideas there are and brainstorming, the more thorough the end result will start to look. I am looking forward to the next sprint and further improve my experience with scrum in general.

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.

Improved Testing Methods

As a beginner programmer, testing my code meant putting in a few inputs, and if the code ran then I had myself a successful program. Recently, I’ve learned of two better testing methods that give you the information needed to ensure that the program can run given any particular scenario. These are Boundary Value Testing and Equivalence Class Testing. While they do work differently, both of these methods are similar in that they each choose an input based on the pool of values given the set conditions.

In Equivalence Class Testing, the focus is on the conditions. Looking at the given conditions, we can determine which values are valid and which are invalid. The range of valid values as well as the range for invalid values are the pool of values that will be tested, which are divided into intervals. For each interval, given an input, if it passes then it stands to reason that all inputs within the range of values will pass for that interval. By the same reasoning, if an input does not pass, all inputs within the range will not pass.

For example, consider a program that is testing for a vending machine, with a variable named cash for the amount of money the machine can accept. The range of valid values for cash is 0 <= cash <= 100. Now if we put in a value for cash that is between 0 and 100 and it passes, that means all values between 0 and 100 will pass. Likewise, if the value does not pass, then all values between the range will not pass. All values below 0 and above 100 are invalid, so testing those numbers will result in an error.

Boundary Value Testing is similar, in that we take valid and invalid values and test them. The difference is that there are 5 particular values we are testing. Say that the pool of values are between 0 and 100 inclusively. The values that will be tested are:
1. the minimum valid value, 0
2. the maximum valid value, 100
3. a nominal value between the minimum and maximum, 20
4. a value just below the minimum, -1
5. and a value just above the maximum, 101.

These inputs test all possible scenarios, therefore if they all pass, then the program is successful. The minimum, nominal, and maximum values test all valid inputs, and the minimum below and maximum above values test invalid inputs.

Equivalence testing and boundary testing are both great methods to use when testing your program. They can both be used to test valid and invalid values, and by doing so, are capable of ensuring that a program is error free.

Helpful Source:

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

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

Erockwood Post #3

Today we will be discussing some things I find interesting in one of my classes. In this class, we are learning about cloud, parallel, and distributed computing. I find it very interesting that we are able to use one fast computer to send tasks to a bunch of slower computers to calculate data in a very quick and efficient manner, rather than just running the data through one singular computer. I also find it interesting how systems like Hadoop are able to maintain data integrity by storing all information in three different places so that if a computer dies, it still has the data in two other places, in which it will then get the data to another computer to keep the data in three places going.

We are currently discussing machine learning, which I personally think is a little overrated. All it really is is just telling a computer when it guesses if it is right or wrong then it adjusts its guesses accordingly until it gets about 99% correct. This is called training. Once the computer is “trained” it is good to go. Statistics and machine learning go hand in hand, as both are used to take data and use that data to predict outcomes based on the input data. One subset of machine learning is data mining, which is many different methods used to extract insights from data.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective- IAM system

I was part of IAM System group in this project and my job is to support and secure other system through keycloak. It was a 3-person team, we are going to implement a third-party system (KeyCloak), deploying the system (using docker) and help other system by embedding in their teams.

What I think that worked well in this sprint was that we were clear on what to read and what to look for. We understood the instructions and started the work that we thought it would be useful for us to know and learn. There is a lot of documentation online for KeyCloack, how it works with other system, with docker, examples that we could try etc. This link is a good source for anyone who is new to Keycloak and wants to know how it works. There is information for everything you might need with keycloak.

https://www.keycloak.org/documentation

Something that I would say it didn’t work well in the beginning it was the amount of information we had to learn and go through. Because this was a project that was new to everyone, we were kind of lost in the beginning and placed issues that weren’t necessary or missed issues that were necessary. It is risky when you are introduced with a new tool and you get lost in the sea of information. Also, we tried to learn tools that we didn’t need it, or we were overthinking some basic stuff that didn’t need a lot of time spending on it.

What we could improve like a team was working more together. Most of the time we spent it working individually and sometimes we were not on the same page. Also, we could have found more examples online or use work from other classes that were close to our project and practice on those during class time. We were focused more in the GitLab board and finding issues than working in what we had and making something more concrete than documentation. Also, when we assigned issues, we could have left it unsigned, as long as, all issues were done by the end of the sprint.

As an individual what I could have changed is being more open with the team and discuss the stuff that were bothering me rather than avoid it and try to hide that I didn’t know how it worked.

In our first sprint we had enough issues for a team of 3 people. Most of the issues were about introduction to Keycloack and figure it out in theory how this system would work with our system. Issues were mostly individual but also, we had ones that we developed in group. I was assigned to getting started with keyclaok which was in group, the authorization services which is an issue that I continue to work on, upgrading that is a closed issue because the way we are going to use keycloack we don’t need to upgrade it and connecting with reporting system to help them in making keycloak work with their system.

We all wrote our documentation on the issues, what we learned and how we are going to use it in the future. The link is provided in GitLab so anyone who comes after us or want to check on what we did, can use it, and help the others too.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/iamsystem/community/-/wikis/home

To the right side of this wiki page there are all the documentation present that me and my team wrote about in this blog. Overall, it was our first experience and it was more like a sprint practice to be ready for the next one.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Unit Testing: What and Why

For this class I felt the most fitting first post was one that explained what unit testing is, as this will be key for understanding more complicated topics further on in the semester. I have only had brief experiences with unit tests in the past, usually being included in code I had from a professor. Thus this is still a relatively foreign concept to myself, granted the general purpose is pretty self explanatory. To tackle this subject I found a blog post that goes sufficiently in depth about this topic, explaining what it is and why it’s useful.

So first things first, what exactly is unit testing? As it’s defined in the post on the testingxperts.com blog, this is a testing type done in the earlier stages of the software. This is advantageous as it allows testers and developers to isolate specific modules for any necessary fixes, rather than having to deal with the whole system. Unit tests usually consist of three phases which are arrange, act, and assert. The arrange phase involves implementing the part of the program that is to be tested in your testing environment. The act phase is where you define the test’s stimuli, what could or could not break the function. Finally there is the assert phase, where the behavior of the program is observed for any potential abnormalities. So now that we have a common understanding of these tests, we can ask ourselves why we should even bother using them.

Admittedly, on the few past occasions I had seen these, I thought the unit tests were mostly superfluous and not very useful. In reality however, these tests can be an invaluable asset for larger systems and can save a lot of time and pain from trying to bugfix further into development if used properly. The primary, and pretty major benefit, is that components of a program are tested early on in the process and individually. This is great for the immediately obvious reason, being that you do not have to worry about progress halting further on in the project because you are testing long before then. Besides this, it also helps the development teams understand the code better, as the tests must be tailored to the specific component they are working on. This familiarity can have other benefits as well, allowing certain members knowledge of how code in some components can be changed or reused for further benefits. Then there is also the fact that this debugging process is simpler than a more traditional approach, as it is done before some of the more complex code is written to interconnect components. These are the major reasons listed in the article, and that I could deduce, but there could very well be more! I do not quite have enough space to discuss the rest, but I would recommend reading the rest of the article if you have any interest in unit testing as it goes into further detail.

Thanks for reading!

Source:

unit testing

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.

Erockwood Post #2

Software testing is very important, as it allows for one to test their/others programs for mistakes, whether it is logical mistakes or syntax mistakes, to ensure that software performs as expected as much as possible. A common testing suite for Java programs is JUnit 5. JUnit 5 comprises of 3 sub-projects, being JUnit Platform, JUnit Jupiter, and JUnit Vintage. The differences between the three are that Platform is used as the base foundation for the frameworks of the Java Virtual Machine(JVM). Jupiter is the model for writing tests and other extensions in JUnit 5. Lastly, Vintage is used for running JUnit 3 and 4 based tests on the newer JUnit 5 platform.

Projects like JUnit are very important, because they allow you to automate testing as much as possible. This allows a tester to save time, by not having to test one thing at a time, they can test all sorts of things at once. It also allows the tester to keep testing methods separate from the main code so they do not accidentally mix and mess some things up. JUnit allows you to write tests using methods like assertTrue, assertFalse, assertEquals, and assertThrows. Each of these are useful in their own ways. For example, assertTrue can be used to ensure that, for example, a customer being created with a customer ID of 1 can be tested to ensure that we expect the customer ID to be 1, then pass in a customer object with the ID 1, to ensure that they are equal. Another thing we can use is assertThrows, to test that invalid parameters throw the correct error, or to make sure an error is thrown at all.

Source:

Stefan Bechtold, S. (n.d.). JUnit 5 user guide. Retrieved March 30, 2021, from https://junit.org/junit5/docs/current/user-guide/

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.