Link to Blog: http://it.toolbox.com/blogs/enterprise-solutions/object-oriented-testing-issues-21274

This blog explains the issues of object oriented testing. Craig Borysowich identifies the strategies of object oriented testing, the strategies for selecting test cases, and the levels of testing, which are all involved in analyzing the testing process. In the beginning of his blog, Borysowich states that testing in an object oriented context must address the basics of testing a base class and the code that uses the base class. Factors that affect this testing are inheritance and dynamic binding. Dynamic binding is also known as dynamic dispatch. Since the factors that affect this testing are inheritance and dynamic binding, it brings up the point that some systems are harder to test than others. For example, systems with inheritance of implementation are harder to test than inheritance of interfaces.

Some object oriented testing strategies include white-box and black-box testing. Two assessments that determine the strategies to select test cases include the assessments of “likely faults” and “likely usage.”

“Likely Faults” involve types of tests which are based on practical experiences of areas in which errors are most likely to occur. For example they can occur from certain syntax in a particular programming language or boundaries such as beginning and end conditions. “Likely Usage” involve types of tests that test to exercise the system in the ways that the user of the system will be likely to use the system, or aim to test completely the elements of the system most likely to be used. These strategies apply to structural and behavioral testing.

The levels of testing that object oriented testing undergoes are Unit, Integration, and Acceptance levels. The Unit test is more effective in the overall system than with procedural unit tests. Integration test focuses on interactions among classes. It is recommended that units be integrated in an incremental fashion at a steady rate. Acceptance test ensure that all of the use cases appear in a test.

I chose this blog because I wanted to know what the necessary processes are when it comes to object oriented testing and its pros and cons. Borysowich briefly explains what these processes and steps are when it comes to object oriented testing and how it can involve Unit, Integration, and Acceptance levels of testing. Knowing the two assessments of “likely faults” and “likely usage” helps determine what strategies to use when choosing test cases. Object Oriented testing will be useful to know, especially when it comes to video games. There are games that have implemented object oriented programming, and it is important to understand the issues and solutions when it comes to testing in thwe object oriented environment.

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

Link to blog: http://www.programmr.com/blogs/5-solid-principles-object-oriented-software-design

This blog gives the description of the 5 different types of design principles. These principles include the Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and the Dependency Inversion Principle. The acronym “SOLID” represents these principles in the given order:

S – Single Responsibility Principle

O – Open-Closed Principle

L – Liskov Substitution Principle

I – Interface Segregation Principle

D – Dependency Inversion Principle

Single Responsibility Principle:

“A class should only have one reason to change” is how the author of this blog describes this principle. This principle states that every class in your software should have one and only one responsibility.

Open-Closed Principle:

“Software entities should be open for extensions, but closed for modification.” This means that software systems should be available for change. Customers will request new features and changes to existing features. Designing a system such that changes or extensions in requirements can be done by adding subclasses instead of changing existing code is a way to avoid rewriting an entire system.

Liskov Substitution Principle:

“Derived classes must be substitutable for their base classes.” This means that there will be some implementation of inheritance from understanding inheritance hierarchies and traps that can cause the open/close principle to fail with certain hierarchies. This principle fixes the violation that a function causes towards the open/closed principle.

Interface Segregation Principle:

“Make fine grained interfaces that are client specific.” This means that client code should not be aware of such a non-cohesive class as one unit. The class should have multiple interfaces and the client code should only be aware of the interface which is specific to its needs.

Dependency Inversion Principle:

“Depend on abstractions, not on concretions.” This means that this principle attempts to prevent a tangle of dependencies between modules by stipulating that entities and high level modules must not depend on concrete implementations but should depend only on abstractions.

The author of this blog identified the five design principles in a way that is easier to understand. He highlights the main concepts by providing a brief one sentence description about each principle. The acronym S.O.L.I.D. also makes it easier to understand on which design principles are which. I chose this blog because I wanted to know more about certain design principles. I previously knew the Single Responsibility and the Open-Closed principle, but didn’t know the remaining three. Understanding these principles will help me in my future career because there will be many different principles I will need to apply as a video game developer considering that there will be many different design principles involved for coding games.

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

This week I read an article on Observer design pattern. Since for my ‘Assignment 2 – Additional Design Patterns’ I was doing lots of research on Observer pattern (which I will be writing a tutorial on), I found this particular post to the most informative one.

Basically, the Observer pattern falls under behavioural pattern, as it’s used to form relationships between objects at runtime. The Observer pattern is the gold standard in decoupling – the separation of objects that depend on each other. The definition provided in the original Gang of Four book on Design Patterns states:

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

The idea behind the pattern is – one of more Observers are interested in the state of a Subject and register their interest with the Subject by attaching themselves. When something changes in Subject that the Observer may be interested in, a notify message is sent, which calls the update method in each Observer. When the Observer is no longer interested in the Subject’s state, they can simply detach themselves.

Fig. The UML diagram definition

James Sugrue, the author of the article, points the main benefit of using this pattern. He mentions that- to pass data onto the observers, subject doesn’t need to know who needs to know. Instead, everything is done through a common interface, and the notify method just calls all the objects out there that have registered their interest. This is a very powerful decoupling – meaning that any object can simply implement the Observer interface and get updates from the Subject.

Sugrue suggests using this pattern to reduce coupling. He argues – if you have an object that needs to share its state with others, without knowing who those objects are, the Observer is exactly what you need.

After reading about the SOLID principles for my first blog, I believe the observer pattern allows for the Open Closed principle, which stated that a class should be open for extensions without the need to change the class. Open Closed principle holds true while using the observer pattern as a subject can register an unlimited number of observers and if a new observer wants to register with the subject, no code change in the subject is necessary. Now, I feel I have a good understanding of the Observer pattern which helps me in writing a tutorial on it.

Source: https://dzone.com/articles/design-patterns-uncovered

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

We’ve been going over the concept of design patterns during the past few weeks, so I thought it would be appropriate to do some research on those most commonly used. Subham Aggarwal has an informative blog on the topic entitled Top 3 Design Patterns in Java. We’ve been examining design patterns written in Java, so I feel that Subham’s blog is a great one to discuss. He provides excellent examples written in the Java programming language.

Subham first explains that design patterns are generally creational, structural or behavioral. He then introduces three design patterns that he speculates are the “top three” used in Java.

1. Singleton Pattern
2. Factory Pattern
3. Decorator Pattern

I covered the Singleton pattern in a recent blog so I will try not to duplicate anything posted in that entry. One aspect that stands out in Subham’s explanation that I ought to mention is his assertion that Singleton is one of the most “inappropriately used” design patterns in Java. Based on what we’ve learned so far, it seems to me that the true intent of Singleton is to have just one instance of each Singleton class. But Subham states that many developers seem to manipulate the pattern in an attempt to have Singleton classes act as global variables, which is not what this pattern is intended to do. Based on Subham’s breakdown and what we’ve learned in class, I would have to say that I believe the Singleton design pattern seems to be a creational one.

Next discussed is the factory pattern, which Subham describes as a way to create certain objects based on the user’s specification. For instance, he provides the following code as an example:

public class ShapeFactory {
 
 // use getShape method to get object of type shape 
 public Shape getShape(String shapeType) {
     if (shapeType == null) {
     return null;
     } 
     if (shapeType.equalsIgnoreCase("Quadrilateral")) {
          return new Quadrilateral();
     }
     else if (shapeType.equalsIgnoreCase("Parallelogram")) {
          return new Parallelogram();
     }
     return null;
     }
}

Something I’d like to add on the subject is perhaps it would be a good idea to develop an enumeration type to define the names of the above given shapes as constants. Also, based on the fact that we are offering a way to create objects here, I would have to say that the factory design pattern is a creational one as well, along with Singleton.

Last but not least, Subham describes the decorator design pattern as one commonly used in Java. The idea here is to “add new functionality to an existing object without changing its structure.” Thus I would have to agree with Subham that this design pattern seems to be a structural one. I do not think we’ve discussed this in CS-343 yet, but I remember using the decorator pattern in a previous course, so I see how it can be useful.

I feel that Subham provides great examples that have helped me better understand these design pattern concepts. The code he provides is well detailed and easy to follow. His blog will be a good reference to me in future projects during my professional career.

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

https://nikic.github.io/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html
This week we analyze why a code may be STUPID. What makes code STUPID are the following:
Singleton
Tight coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication
Singleton, what is wrong with that? According to the example code provided in the article, the singleton allows access to the DB from anywhere using the getInstance() method. In addition, it ensures that there is only one database connection at a time. This is not an issue until a second connection to a different database is needed. In this case, when the application grew larger, the developer needed to change the singleton to have a getSecondInstance(). However, this isn’t a singleton anymore. Another issue is that the getInstance() function binds the code to the DB classname. This means that the DBclass can’t be extended. In this case, when a developer wants to optionally log query performance data to the APC, tight coupling to the class name will not allow it to do so. Dependency injection would have solved the problem, however this is not allowed in singleton pattern. What the writer introduced was what can be called a “hack”, but this is bad coding practice. The last point to be disappointed in is that the getInstance() method allows global access from anywhere using the DB. However, in PHP we learned to avoid the use of the global keyword. Global instances in singletons creates non-obvious dependencies, making the app harder to reuse and test. So, this is impractical coding practice.
The singleton issue can also be generalized to the issue with static methods and properties. For example, the Foo::bar() method will tightly couple the code to the Fooclass. This prevents the Foo function from being extended. This makes it harder for the code to be reused and tested. The example provided is the House class with the constructor function for the variables door and window. The question to ask is how would you replace the door or window in the house class. The answer is you can’t! Instead, the dependency injection can be introduced, however the House class is an example of stupid code.
Finally, we stop at the U in STUPID which stands for untestability. Unit testing is important and if we cannot test we cannot verify its proper functionality. If we don’t test we can end up with broken code. Making a code hard to test is in this case stupid code. What makes a code hard to test? — tight coupling. Dirty hacks can be used to avoid these issues, but we would rather not have broken codes in the first place. Overall, good coding practices means that it can be easily tested.
I chose this blog post because it introduces the disadvantages of the singleton design. This further intends what I have learned in my first blog post on Singleton patterns. Singleton in this case is criticized even for its advantages in creating a global state for a single instantiation. In this case, it is criticized as stupid code because it does not allow the developer to extend the code without modifying it to include a second instance, making it a dupleton.
I chose to learn about STUPID coding practices in order to improve my own coding practices as a developer since it provides good examples for how to avoid bad code and how to improve upon it. By, following some of the guidelines introduced here, this helps to make the code easily extensible without modifying its previous functionalities.

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

https://blog.testlodge.com/software-testing-best-practices/
This week we ask what are the best practices for testing. Although this article suggests 6, we will only discuss 5 in this blog post. The first as discussed in the article is to understand the project objective. It is critical to understand the objective of the overall project from a business and technical perspective. It is also important to have every member of the team know the project’s goals, not just the scope of their testing. Although it is typical for the whole project to be divided among several team members with each team concentrating on only their area of testing, it is always beneficial to have the entire application and architecture in mind. This helps them to know about all of the different components, dependencies, integration points, and data flow. It is also useful for testing defects to be aware of the whole application flow to be able to nail down the root cause. Overall, knowing the objectives helps to identify better test scenarios.

The second best practice is to plan and define strategies. Planning is crucial for success. Therefore, it is recommended that every software developer makes it their daily routines. The article suggests the following activities as part of test planning:

Select the resources with the right skill set.
Identify risks.
Prepare test schedule.
Define strategy, which includes defining the overall strategy/plan to be taken in order to test an application.

The third best practice is to design scenarios and enforce reviews. Standard design phases includes the development of test scenarios and test cases and the typical reviews by stakeholders.

The fourth best practice is the obvious, communication. Every working team requires communication either through emails, the phone, on chat, or in person. What is the case where there is a lack in communication? Consider a defect that has been marked as fixed by a developer. Once the team tests it and finds out that it is not working properly, they mark the issue as unresolved although the other development team had stated that it had worked fine on their end. This demonstrates a lack in communication. The best solution is to mark the defect as unresolved and provides specifics and detailed explanations on what had been tested on multiple browsers and could not be corrected. The key is to be as detailed as we can be in our communications with the other development team.
The final best practice is to identify the scope of automation. Automation in this case can be achieved by writing scripts to perform a repetitive job. This helps to reduce manual efforts. The article suggests the following tips to help in identifying the scope of automation:
Identify the most difficult area that you hate to do, but crucial in the test design, meaning you are forced to test it. The second suggestion is to focus your attention on how to automate the task.

From the 5 best practices, however, I found 3 to be the most useful and that is to know the overall objective of the whole project, to plan around it and finally communication is always the key to a successful career. From experiences with software development, I found that adhering to the overall goals of the project helps to organize the code, which is what every programmers wants and it is what these guidelines and principles teaches us about, that is to clean up our codes. Knowing the overall objectives of the design helps to keep the team on track and it helps to create cohesiveness in the product. This helps to reduce defects and debugging. The other guideline that I found most useful is effective communication, which is require in every field of study. Effective communication helps to speed along the project.

Overall, I chose this blog post in order to compare the suggested best software testing strategy with my own experiences in software development. I found the first, second, and fifth guideline to be useful in software development.

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

Considering we’re discussing JUnit in class, I want to learn how to use it as efficiently as possible. For those who are not aware, JUnit is a popular unit testing framework for the Java programming language. Since unit testing is an important concept in Software Development, learning more about the workings of JUnit should not only help me with my studies, but also with my professional career.

I found a good blog offering some tips and pointers on the subject, entitled JUnit Best Practices by Kyle Blaney. The main point seems to focus on the importance of performing efficient unit testing with the JUnit program.

Before going into JUnit specifics, Kyle starts off by stressing that unit tests ought to be “extremely fast” and “extremely reliable.” Due to present technologies, we seem to expect computers to run at the proverbial speed of lightning. Because of this, I believe it is considerable to expect each test to be completed within milliseconds. Also, I agree that unit tests should be reliable in the following sense: they should be failing when the code is broken and passing when the code is not.

In regards to JUnit, Kyle brings up quite a few points, the following of which I felt specifically relate to the course material. This pertains to what we’ve previously discussed about unit testing so far, and what we will likely be covering in the near future.

Kyle explains that we should be running our JUnit tests completely in memory. This means we should not be accessing outside resources during our testing. I agree, because if we cannot get a reliable connection on these outside resources, it will only slow down or possibly halt our unit testing completely.

Another important point that Kyle brought up is that unit test methods should only be performing one assertion. His reasoning is as follows: we cannot be certain that all the assertions occur even if the method appears to have passed. This seems to be in relation to something we’ve learned in our school’s computer science program: “Methods should do one thing and one thing only.” That way, it is much easier to trace our code and figure out what it is supposed to be doing.

We’ve also discussed in class that we should be using JUnit assertion methods that best match the context of our testing. One example Kyle gives is when to use assertTrue versus assertEquals:

Use assertTrue(classUnderTest.methodUnderTest()) rather than 
assertEquals(true, classUnderTest.methodUnderTest()).

Kyle goes into great details within his blog. Along with the points that I’ve discussed in my own blog, he offers code samples of what not to do, and most importantly, what we should be doing to perform the most efficient JUnit testing possible. I found his blog to be quite helpful and learned a lot from reading his take on JUnit “best practices.” Because of this, I expect his strategical insights and sample code will be useful to me in my future career in software development.

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

Model-View-Controller

          This week, I chose to write about a blog that went over the understanding of Model-View-Controller. The post first started by explaining each term separately by saying that the Models represented the knowledge while the View was a visual representation of the Models and the Controllers were the links between the user and the system. It talked about Models first, saying that most of the time there should be a one to one correspondence to make sure everything is easily understandable. The blog then goes on to talk about Views as a presentation filter, it would be used to easily convey information. As stated before, this is helpful when it is a visual representation of the Model but it can also be connected to the model which allows it to know more about the attributes and data. This leads to the controllers that essentially allow the user to see outputs based off of menus and other ways of giving commands and data. It uses this output to then make changes back in the Views section which will them give out another output.

          I chose this article because it seemed important to know more about how to explain code using models and controllers in this sense to other people. This post used examples that allowed this idea to be understood much easier for me, as the summary was a bit confusing. When they used the example of HTML code in the browser it made much more sense. The way I understood it after that was that the model was the information the creator wanted to put into HTML while the CSS was the view which acted like the “code” that displayed everything in a clean visual representation. This all came together within the browser which they linked to a controller as it is what combines and connects the entire thing. As I said before, the content had ok definitions but the examples they used made up for it since it allowed an easier understanding. I thought this topic was important since we will be learning about this subject as it is a software architectural pattern. This material affected me by showing me a system to show the user simplified information through the use of code. I think that if this were to be implemented within coding, it would be best used as a way to reuse code along with implementation of user interfaces. As a software architectural pattern, I could see this being important to future practices as it seems to be used a lot within popular programming languages and even web application development.

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