Author Archives: jneal44

CS-343 Post #1

After the past few activities in class I was trying to think of what I wanted to look for to do my first blog post on. The one topic that caught my attention and I wanted to look more into was Design Patterns from activity 4. The strategy design pattern that we used in model 8 to improve the DuckSimulator seemed very effective to me, and I wanted to look more into design patterns after reading a bit about them in models 8 and 9. I found a blog post that goes over the strategy design pattern and when reading it, it went more in depth with the pattern than I thought it would based on the title of the post, “Keeping it Simple with the Strategy Design Pattern”, from Bits and Pieces.

The post briefly goes over Object Oriented Programming, then it focuses on the different aspects of the strategy design pattern. The parts of the pattern that the post goes over are its basic idea, structure, examples, authentication strategy, the problems it solves, SOLID principles, how it’s used in JavaScript, and when to use it.

Some of the material was familiar to me from previous courses that I didn’t think would show up, but it made sense that it did, such as the sorting algorithms, such as bubble sort and linear search, being used for the strategies being represented based on the data and objects in the program. Diagrams used for the pattern also were very similar to the ones used in the activity to show the structure of the pattern with the implementation of context, interface, strategy, and concrete strategy.

What was less familiar to me where the authentication schemes and strategies, such as basic and digest, that are brought up later on in the post. I did not know the specific schemes brought up, but I got the idea behind their usage for authenticating data in the program. The schemes were also used in examples for the strategy design pattern by showing an interface being used to have an authentication method that is implemented by the schemes.

The main problem resolved by the pattern is the hardcoding of the program, which can make in run less smooth and more complex/complicated than it needs to be. Using a pattern prevents this by breaking down the program into different tasks and classes that keeps the algorithms more understandable and usable. This is reflected in another example with a given Printer class with multiple classes, but is also shown in the final DuckSimulator version.

In conclusion, the strategy design pattern is effective at improving complex programs, keeping the classes manageable, and keeping the methods and algorithms separated from each other.

Link: https://blog.bitsrc.io/keep-it-simple-with-the-strategy-design-pattern-c36a14c985e9

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Introduction : CS-343

Hello, I am Jeffery Neal, and I am a senior enrolled in Cs-343. I look forward to learning in this course and posting in the blog during this semester.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Blog Post #5 Static Testing

After working with Checkstyle in the recent activity, I wanted to look more into other static testing tools, but this led to me focusing on the purpose and function of static testing. I had an idea on how it worked prior to the activity, got practice using one of its tools in the activity, but I wanted to read more about static testing in general to get a better grasp on the concept and how it works.

Static testing is based around testing code without actually running the code, as opposed to dynamic testing that checks the code when it runs. The two main static testing techniques are manual examination and automated analysis using tools. Static testing is effective because it can catch early mistakes, takes less time to test, and leads to improved productivity. Checkstyle was the main tool that we worked with, but there are others such as Soot and SourceMeter.

I think the main aspect of static testing that I wanted to learn more about was how it compared to the normal testing that we have been working with, and after working with stubs and mocking in the past activities, it feels similar to mock testing because it seems more about testing behavior than state. It felt like that way to me because JUnit tests can still run when the static test picks up errors if the errors are programmed to be ignored, similar to how a JUnit test may pass but not work properly because it picked up a different method that had the same return type, which is the purpose of behavior testing.

However, with static testing, the proper method can be called and the code could have the right behavior and state, but still not pass because of errors found with the test, such as Checkstyle, which finds errors due to the selected coding style/standard. These errors can also be coded to ignore and still run.

https://www.guru99.com/testing-review.html

https://www.guru99.com/static-dynamic-testing.html

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Blog #4 Mock Testing and Dependencies

I wanted to learn more about mock testing after working with it and other testing approaches in the recent activities. There are some parts of mock testing that I am think I could understand better after doing some more reading on it.

The process and purpose of mocks make sense to me, where mocks are used to simulate behaviors for tests and focus more on the code itself. Because of this, mock testing is based on the behavior of code while unit testing is state based. State based is for the values you get from the code while behavior based is for checking if the right method is called. Behavior based is important because you can get the right values, but you might not call the right method if there are methods with similar return types and parameters.

I think where I had some misunderstandings at first was when it came to dependencies. Mock testing is based around dependencies and it seem like mock testing will be more difficult if you have some trouble with dependencies. I haven’t worked as much with dependencies as other areas with code, and I had a little trouble with it in a past assignment.

Dependencies are other programs that the main code relies in order to work, with JUnit being one of the main examples that we work with. Where I have some trouble with this is less with understanding the concept and more with some parts of how it works in the IDEs. I sometimes get errors from not properly setting the dependencies and get stuck on them for a while. Mockito is another one we have started working with that was giving me some trouble in a similar way.

I have a better grasp on dependencies after reading more about them and mock testing, and I hope to overcome problems that I have working with mock testing as we continue in the activities.

https://devopedia.org/mock-testing

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Blog #3 Decision Tables

Decision Tables have been one of the tricker concepts for me to understand and work with, and was one of the tougher sections on the recent exam for me. I think part of it is me mixing some of the terms up, such as at the conditions and rules, which leads to weird looking tables or I would just get stumped. I wanted to read more articles about decision tables to better understand what I else I might be missing and how to improve.

I understand the main concept of using the tables as another way to show different combinations of values for the variables, with the conditions acting similar to the previous boundary and equivalence classes that we have been working with, and actions simply being the output. So I think it’s the idea of the rules and what goes in those columns that is what I am having trouble with.

At first I though that rules were the classes and was confused on what the conditions were, but after understanding the difference between them, I had a better grasp on making the tables. I was able to set up the conditions and actions after this, and now I wanted to focus on understand rules and what is put in the columns.

The rules themselves are similar to case numbers from boundary and class testing, where they identify each combination of input and output values. Because of these, we are usually able to group rules together that have several input values matching a condition and have a shared output , such as multiple values that fall in the range between 0 and 10 that match an action.

I have a better understanding of decision table testing now after doing more reading on the subject from other articles and activity 8 and seeing my mistakes with my understanding of rules, possible input and output values, and the conditions and actions.

https://www.guru99.com/decision-table-testing.html

Decision Table Testing

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Blog #2 Weak vs Normal (Equivalence Class Testing)

I wanted to look more into equivalence class testing after working with it on some of the class activities and having some trouble understanding some of its aspects, specifically the differences between weak and strong, and single fault assumption vs multi fault assumption.

Equivalence Class Testing-Black Box Software Testing Techniques

Weak and Strong testing come in two forms each, Normal and Robust. Weak testing is meant to work with the single fault assumption, where one variable from each class is tested. With Weak Normal, only valid values are tested, while Weak Robust tests valid and invalid. Strong Normal testing works with the multi fault assumption, meaning that each valid possibility is tested, and Strong Robust testing works with each valid and invalid possibility.

Where I was getting confused and had to look more into equivalence class testing was the difference between working with one variable from each class and working with all possibilities, or more specifically, the single fault assumption and the multi fault assumption. When I was first looking at it and tried working on problems about this, they seemed the same to me because with each entry in the table I was making and other examples I looked at. It looked to me that both worked with multiple values of the variables that are in the range, so I got caught up on trying to see where I was making a mistake in my understanding.

Where I think I was making my mistake, and what I think the difference between the two is, is that with Weak test cases, one of the variables stays constant while the other goes through its different values. Then after several of those test cases, the latter variable stays constant at the nominal and the former changes values. Through this, one of the variables is getting testing at a time with the other values of the other variable, which is where the idea of testing one variable from each class comes from. I may be wrong about this, and this is just how I understood it.

Distinguish between single and multiple fault assumption

So with Strong testing, this is where you can use any combination of valid values for the two variables for the test cases. This would increase the number of cases due to more possibilities. Then with Weak Robust and Strong Robust, you mostly do the same but include the invalid values with the valid ones from the Normal testing. In Weak Robust, one variable stays at the nominal while the other goes through a range of valid and invalid values, then do the same for the other variable. In Strong Robust, all valid and invalid possibilities for the variables are tested, leading to the highest amount of test cases out of the four techniques.

I think I have a better understanding of the differences between them after delving more into equivalence class testing and the different techniques associated with. My misunderstanding was how variables were being tested with the two assumptions because they seemed the same at first, but I can see how they are different now in their test cases and methods.

https://www.professionalqa.com/equivalence-class-testing

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Blog Post #1: JUnit 4 vs JUnit 5

For my first post, I got the idea to look more into the differences between JUnit 4 and 5 after the video and questions from the first Advanced Assignment for CS-443.

JUnit 4 was first released in 2006, and was the prior main framework for Java developers. 4 built upon assertions and annotations for methods and testing, and was used for over a decade. However, a big change was needed because of growing issues with JUnit 4 with modularity and extensions. This big change came in the form of JUnit 5.

JUnit 5 was then released in 2017, and JUnit 5 is meant to improve on JUnit 4, so it has multiple advantages over the latter framework, such as:

  • Divided into three bundles: Platform, Jupiter, and Vintage, instead of being a single jar file.
  • With JUnit 5, you can import what is necessary, while JUnit 4 imports the whole library.
  • Multiple test runners can run at a time on JUnit 5, while JUnit 4 only allows one at a time.
  • Additional annotations, such as annotations for nested loops and custom extensions
  • Lambda expressions
  • JUnit 5 uses Java 8 and higher, while JUnit 4 stops at Java 7.

JUnit 5 is the main framework that is used today for Java, and continues to get updated to this day. JUnit 4 was efficient for many years, but JUnit 5 is the better framework by improving on 4s flaws and continuing to improve as time goes on.

https://howtodoinjava.com/junit5/junit-5-vs-junit-4/

https://blogs.oracle.com/javamagazine/migrating-from-junit-4-to-junit-5-important-differences-and-benefits

https://www.baeldung.com/junit-5-migration

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Introduction

Hello everyone! I am Jeffery Neal and this is my first blog post. I am a Junior in Computer Science and enrolled in CS-443. I look forward to the rest of this semester!

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.