B7: Black-Box vs. Gray-Box vs. White/Clear-Box Testing

http://blog.qatestlab.com/2011/03/01/difference-between-white-box-black-box-and-gray-box-testing/

          I found an interesting bog post this week that talked about the differences between White Box, Black Box, and Gray Box Testing. It started with black box testing by explaining that it is an approach where the tester has no access to the source code or any part of the internal software. The basic goal of this testing type is to make sure that inputs and outputs work from the point of view of a normal user. The blog goes on to talk about the main features of this testing type by explaining that the test design is based on the software specification and detects anything from GUI errors to control flow errors. It is a short prep test which helps make the whole process much faster but lacks the needed detail to test individual parts of the software. The blog goes on to talk about white box testing which allows the tester to have access to the source code. This testing allows the tester to know which line of code corresponds with which functionality. This allows more detail for individual tests on code functionality. It allows more detailed testing with the ability to anticipate potential problems but takes more time and can be complex/expensive. As for grey box testing, the blog explains that it is an approach where testers only have a partial understanding of the internal structure. The advantages and disadvantages of this technique are incorporated from the related white and black box testing.

       I chose this article because I remember that we learned about this subject in the beginning of the year. I wanted a better knowledge about the advantages and disadvantages which is what sparked my initial curiosity. I found that this content was really interesting because it explains how testing can be when dealing with different amounts of access to data. I enjoyed how the post explained the types of testing sequentially while also explain how they can be different from each other. I was able to grasp an understanding of these testing types while also understanding the importance and vital role that they play depending on the situation. The most interesting part of the blog post was the grey box testing because it combines the aspects of black and white box testing. It also deals with regression testing and matrix testing which are very important when testing code bits of code at a time. I found that the diagrams used in the post allowed an easier flow to the readings which helped me understand it better. I found the blog to be a great source that summarized and simplified the detailed ideas within the post.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Visitor Design Pattern

Visitor Design Pattern

For this week’s blogpost I will be discussing another design pattern, this time I will talk about the Visitor Design Pattern discussed on Source Making’s website. Essentially the Visitor design pattern allows you to add methods to classes of different types without much altering to those classes. Allowing you to make completely different methods depending on the class used. Because of this you can also define external classes that can then extend other classes without majorly editing them.   Its primary focus is to abstract functionality that can be applied to an aggregate hierarchy of element objects. This promotes designing lightweight element classes due to the processing functionality being removed from the list of their responsibilities. New functionality can be added later easily by creating a new Visitor subclass. The implementation of Visitor beings when you create a visitor class hierarchy that defines a pure virtual visit() method in the abstract base class for each of the concrete derived classes in the aggregated node hierarchy. Form here each visit() method accepts a single argument – a pointer or reference to an original Element derived class. In short, each operation to be supported is modelled with a concrete derived class of the visitor hierarchy. Adding a single pure virtual accept() method to the base class of the Element hierarchy allows accept() to be defined to receive a single argument. The accept method also causes flow of control to find the correct Element subclasses, once a visit method is involved the flow of control is vectored to the correct Visitor subclass. The website listed below goes into much more detail into what exactly happens but here I summed it up so that most should be able to follow. But essentially the visitor pattern makes adding new operations easy, simply add a new Visitor derived class but if subclasses are not stable keeping everything in sync can be a bit of a struggle.

Example of Visitor Design Pattern

The example they use in the article is that based around the operation of a taxi company. When somebody calls a taxi company (literally accepting a visitor), the company dispatches a cab to the customer. Upon entering the taxi, the customer, or Visitor, is no longer in control of his or own transportation but the taxi driver is.

All in all, I thought this website was really good at explaining what the Visitor Design Pattern is. I have used this website before for previous research into design patterns and more.

 

https://sourcemaking.com/design_patterns/visitor

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

IT IS TIME TO DECORATE THE HOUSE!

Well Halloween has come and gone and you know what holiday is next.  Thanksgiving that’s right and you need to decorate quickly before it is time to switch to Christmas decorations! Well if you had to do something similar in the coding world you would use the Decorator design pattern. The decorator design pattern is a design blueprint that seeks to eliminate complex hierarchy’s and allow the programmer to define the object at run time. The upside to the decorator pattern is the easy of adding new components. You essentially create an object as an interface and then create extensions of the object through a decorator class that implements that interface. Which allows you to set all the methods, or information that you want the object to have like price, or description and define that addition price or description with a decorator object. To visually think about this design pattern you can think of a rubber band ball. It has one bouncy ball in the core that is the interface, and each rubber band added to the ball is surrounding that interface object the ball. As you add more rubber bands the object is still a ball, but it is “decorated” in rubber bands. The rubber bands are now an additional quality of the ball, and extension of the ball.

Consider now your house the dining table if you wanted to create a decorator pattern for the table for the next two holidays you could do it easily with the decorator pattern. Your base object or interface would be the table. From there how you decorate it is up to you if you create a thanksgiving table cloth object you can at the time of creating the table add the thanksgiving table cloth in the creation of the table. Then when you are ready for Christmas on November 23 at 00:01 you can just create a Christmas table cloth decorator object and apply it at runtime for it to be added to the table. Then additionally you can create other decorations to be added and you don’t even need to delete the class for the code to work you simply just don’t need to call it at run time.

Overall the decorator pattern helps to avoid an inheritance tree that relies heavily on the parents. This lets you define objects that may or may not be used and call them at run time to decorate your object. For additional information you can check out the link below for additional research that I have done on the topic of the decorator pattern.

https://gitlab.com/AFinneran/homework3-decorator/blob/master/Homework%203/343hw.md

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

Keep Software Design Simple

Good day my dear reader! With it being quite deep in the semester now, one can correctly assume that I have learned quite a bit regarding Software Design and I have. With all this new information, I read an article that has helped me put all of it in perspective. This article was Simplicity in Software Design: KISS, YAGNI, and Occam’s Razor from the Effective Software Design blog.

This particular blog post is all about keeping your software design simple and details three different design principles to keep in mind while designing software and the effects of making a design too complex and conversely too simplistic.

The first principle is, “Keep it simple, stupid” more commonly known as KISS heralding that keeping designs simpler is a key to a successful design.

“The KISS principle states that most systems work best if they are kept simple rather than made complex; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.”

The next principle is, “You Aren’t Gonna Need It” or YAGNI stating that functionality should be added only when it is actually needed and not before.

The last principle is Occam’s Razor, saying that when creating a design, we should avoid basing our designs in our own assumptions.

Not following these principles can result in complex designs that lead to feature creep, software bloat, and over-engineering. It could alternatively result in oversimplification where the design is too simplistic. This could lead to trouble down the line in areas such as maintainability, extensibility, and reusability.

Reading this blog post, made me sit back and think about my previous programming assignments. Looking back, my programs have been indeed, overly complex. A great quote provided in the blog post is from Brian Kernighan.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

This gave me a good chuckle and is something I can definitely agree with and have done in the past. I will admit, that I had never considered the consequences of oversimplification. When the majority of your programs are single use for a specific scenario, you never really have to consider the consequences outside of getting the program done. An excellent quote provided by the author in the blog is from Albert Einstein.

“Keep it simple, as simple as possible, but not simpler.”

I completely agree with the author here that this quote expresses the danger of simplistic design that must be considered. It is easier to make things too simplistic rather than hitting the sweet spot of as simple as it needs to be.

This article will be one that I intend to keep in mind whenever I sit down to start a new programming project, especially as class projects start to roll up this time of the semester and I do believe that simple software design will greatly improve any designs that I come up with, keeping KISS, YAGNI, and Occam’s Razor in mind.

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

On the Differences of Test Doubles

In his post “Test Double Rule of Thumb“, Matt Parker describes the five types of test doubles in the context of a “launchMissile” program. Using a Missile object and a LaunchCode object as parameters, if the LaunchCode is valid, it will fire the missile. Since there are dependencies to outside objects, test doubles should be used.

First, we create a dummyMissile. This way we can call the method using our dummy, and test the behavior of the LaunchCodes. The example the Parker gave us is when testing given expired launch codes, the missile is not called. If we passed our dummy missile and invalid LaunchCodes to the function, we would be able to tell if the dummy variable was called or not.

The next type of test double Parker explains is the spy. Using the same scenerio, he creates a MissleSpy class which contains information about whether or not launch() was called, the flag would be set to true, and we could determine if the spy was called.

The mock is similar to the spy. Essentially, a mock object is a spy that has a function to verify itself. In our example, say we wanted to verify a “code red”, where the missile was disabled given an invalid LaunchCode. By adding a “verifyCodeRed” method to our spy object, we can get information from the object itself, rather than creating more complicated tests.

Stubs are test doubles that are given hard-coded values used to identify when a particular function is called. Parker explains that all these example tests have been using stubs, as they all return a boolean, where in practice real launch codes would be provided. But we do not need to know about the LaunchCodes to test our LaunchMissile function, so stubs work well for this application.

The final type of double Parker describes is the fake. A fake is used when there’s a combination of read and write operations to be tested. Say we want to make sure multiple calls to launch() are not satisfied. To do this, he explains how a database should be used, but before designing an entire database he creates a fake one to verify that it will behave as expected.

I found this post helpful in illuminating the differences between the types of doubles, as Parker’s use of simple examples made it easy to follow and get additional practice identifying these testing strategies.

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

The Four Levels of Testing in Software

For this week, I have decided to read “Differences between the different levels of testing” from the ReqTest blog. The reason I have chosen to read this blog is because it is crucial to understand the basis for each testing level. It will help in understanding the system process in terms of test levels even if it is short and simple.

This blog post basically goes over the four recognized levels of testing. They are unit or component testing, integration testing, system testing, and acceptance testing. Unit or component testing is the most basic type of testing and is performed at the earliest stages of the development process. It aims to verify each part of the software by isolating it and then perform tests for each component. Integration testing is testing that aims to test different parts of the system to access it if they work correctly together. It can be adopted as a bottom up or top down method based on the module. System testing is testing all components of the software to ensure the overall product meets the requirements specified. It is a very important step in the process as the software is almost done and need confirmation. Acceptance testing is the level of testing whether a product is all set or not. It aims to evaluate whether the system compiles with the end-user requirements and if it is ready to be deployed. These four types of testing should not only be a hierarchy but also as a sequence for the development process. From all these testing levels that show the development process, testing early and testing frequently is well worth the effort.

What I think is interesting from this blog is the simplicity of explaining each testing level. Each testing level in the blog has a small definition in what they suppose to do, when they are used, and an example in the process. This content has changed the way I think it would work by giving the explanations in a format that is not too complicated to follow.

Based on the contents of this blog, I would say that this blog is short and very easy to understand. I do not disagree with the content given by this blog because the ideas given for the testing levels do connect for the development process. For future practice, I shall try to adopt a mind of constant alertness to my projects with these four levels. That way, I can be more aware for detecting software errors.

Link to the blog: https://reqtest.com/testing-blog/differences-between-the-different-levels-of-tests/

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Writing Great Unit Tests

In the blog post Writing Great Unit Tests: Best and Worst Practices, Steve Sanderson talks about the best and worst practices when writing unit tests. He goes over the true purpose of unit tests (each examining a unit of your code separately and as a whole cohesively working together to provide value that is more complex and subtle than the sum of its independently tested parts, not for finding bugs), as well as the purpose of integration tests (automate the entire system to detect regressions). At the end of his post, he also gives several useful tips for writing great unit tests, such as making each test orthogonal, or independent, to all other tests.

The reason I chose to talk about this blog post is because I think it’s definitely something that’s commonly overlooked by developers. As Sanderson said at the beginning of his post, “Even if you’re a brilliant coder with decades of experience, your existing knowledge and habits won’t automatically lead you to write good unit tests.” For people looking to get into software development, I think it’s important to learn how to write great unit tests early on so as to avoid having to clean up a self-inflicted mess in the future.

I found it interesting when he described the difference between unit tests and integration tests, as well as the problems that bad unit tests can cause. This image found in his post is useful for visualizing this:

image

The last section in which he gives practical advise for writing great unit tests is also something that I think will be useful in the future, although I think the formatting may have been messed up.

One thing that I have a hard time not necessarily agreeing with but understanding is how he said that unit testing isn’t for finding bugs. I think that, for example, if you were to make a change to the way a function performs its task (perhaps to optimize the code) while not trying to affect the end result, one of your unit tests failing because of this could be classified as “finding a bug.”

Source: http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Service Locator Pattern

For this week’s blog article, I will be looking at the Service Locator Pattern. The article explains how the Service Locator Pattern is a relatively old pattern that was originally used to improve the modularity of an application by removing the dependency between the client and the implementation of an interface. There are many principles that enable you to implement maintainable applications: the Open/Closed Principle, the Liskov Substitution Principle, the Interface Segregation Principle, and the Dependency Inversion Principle. Although these principles are all helpful, they all share the same issue. You need to provide an implementation of the interface, and if that’s done by the same class that uses the interface, you have a dependency between the client and the implementation.

The Service Locator Pattern avoids this dependency altogether. The service locator pattern acts as a central singleton registry that provides implementations of different interfaces. The component that uses the interface no longer needs to know the class that implements the interface, and instead of instantiating the class, it gets an implementation from the service locator. You can implement the service locator as a static service locator that uses a field for each service to store an object reference. Or you can create a dynamic service locator that keeps a java.util.Map with all service references.

Although the Service Locator Pattern can be helpful there are concerns against it and it is also largely outdated by the Dependency Injection pattern. The three most common concerns against the Service Locator Pattern are that all components need to have a reference to the service locator, which is a singleton, the service locator makes the application hard to test, and a service locator makes it easier to introduce changes in interface implementations.

The service locator pattern is just one of the many different patterns that you can use to decouple a client from the implementation of an interface. The pattern uses a singleton registry that provides an instance of a service interface. This helps to move the dependency to the interface implementations from the client of the interface to the service locator class. Although the pattern has some downfalls and is slightly outdated, it can still be used in certain situations.

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

Anti-patterns

This blog https://effectivesoftwaredesign.com/2010/12/22/identifying-anti-patterns/ titled “Identifying Anti-Patterns” discusses what it refers to “anti-patterns”, a category of common code practices that resemble the organizational structure provided by the use of design patterns, but are actually counterproductive and not a good design. I think that the existence of anti-patterns is interesting; in an effort to write code that is well structured and easy to follow, it is actually made worse. The blog post points out that anti-patterns are most commonly used by programmers who are inexperienced and end up writing code with bad design and bad performance, but it is also possible for experienced programmers to do well in implementing a good design, but at the cost of a significant sacrifice on performance. In general I think it would be common for the implementation of a design pattern to have some performance trade-off with readability and maintainability, so there must be some line as to where a design pattern would become an “anti-pattern” if it were to cause some level of a decrease in performance. Design patterns are commonly used for the sake of scalability so that a program with a well-structured foundation will be easier to maintain as it becomes larger, but these design patterns that are implemented during the beginning of the development of the program may seem like unnecessary anti-patterns that are unnecessarily abstract for the current scope of the program. It may be difficult to identify anti-patterns given that excuses and arguments can be made for why code should be implemented in a certain way. Over-complicating things has an impact on performance, but an organized foundation is well suited for a large project, and re-implementing a lot of code as a project grows would likely be more counterproductive than being careful from the beginning. There definitely are some practices that are objectively wrong, but this blog post does not go into any examples, and it is also possible that what may be identified as an anti-pattern could be a false positive. When there is a trade-off between design and performance, it makes the most sense for an anti-pattern to refer to a mistake that is ineffective in both areas.

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

Angular

Today blog is about a brief introduction on angular. This article starts off explaining what a scope is. This was not new to me because I have a little background in programming but I assuming this part of the blog is for people who is just started programming and pursued angular as the focused. The definition of angular in this article “a structural framework for dynamic web applications, made in pure JavaScript.” What does structural framework mean? I didn’t know at first, but this article explains well, it’s states that “angular is a structural framework because it allows us to use HTML as a template language and extend its syntax to express the components of the applications in a cleaner and simpler way.” Basically, I think its take complex syntax like HTML and converts it to a simpler format. AngularJS uses MVC where whatever is changed in the controller is updated in the view. It’s appropriate to use AngularJS when the it is a large application, when you need a good structure, when you need a robustness, and when the application is complex. The controller is a tool that Angular provides. A controller acts as the middleman between various views and models. The web view or mobile view is the user interface, it’s what the user sees, and the model is the database. A module is a gives structure to an application because it acts as “a container for controllers, services, filters, directives.” I learned that it reusable and doesn’t require to run in any specific order because it can slow down the execution time and it great for unit testing. There are also two types of service, Factory and Service. They both services are ways to create an object. After reading this blog I learned a little more about Angular. This article was helpful but didn’t have much example of the topic which I would like because some topics I wanted to know what its visual look like. All in all, this article was helpful, and it changed the way I look about this topic Angular because it seems more complex which I will research further but for now this is all.

https://www.belatrixsf.com/blog/an-introduction-to-angularjs/

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