Category Archives: Week 4

Code Coverage Alone Probably Won’t Ensure Your Code is Fully Tested.

For this week’s CS-443 self-directed professional development blog entry I read a blog post written by Mark Seemann, a professional programmer/ software architect from Copenhagen Denmark. The blog post I read is entitled “Code coverage is a useless target measure,” and I found it to be quite relevant to the material we’ve been discussing in class the past couple of weeks, especially regarding path testing and data-flow testing. In this blog post, Seemann urges project managers and test developers not to just set a “code coverage goal” as a means for measuring whether their code is completely tested or not. Seemann explains that he finds this to be a sort of “perverse incentive” as it could encourage developers to write bad unit tests for the simple purpose of just covering the code as the project’s deadline approaches and the pressure on them increases. He provides some examples of what this scenario might look like using the C# programming language.

In his examples, Seemann shows that it is pretty easy to achieve 100% code coverage for a specific class, however, that doesn’t mean the code in that class is sufficiently tested for correct functionality. In his first example test, Seemann shows that it is possible to write an essentially useless test by using a try/catch block and no assertions existing solely for the purpose of covering code. Next, he gives an example of a test with an assertion that might seem like a legitimate test but Seemann shows that “[the test] doesn’t prevent regressions, or [prove] that the System Under Test works as intended.” Finally, Seemann gives a test in which he uses multiple boundary values and explains that even though it is a much better test, it hasn’t increased code coverage over the previous two tests. Hence, Seemann concludes that in order to show that software is working as it is supposed to, you need to do more than just make sure all the code is covered by unit tests, you need to write multiple tests for certain portions of code and ensure correct outputs are generated when given boundary-value inputs as well.

The reason I chose Mark’s blog post for my entry this week was because I thought it related to the material we’ve been discussing recently in class, especially data-flow testing. I think it is important for us to remember, when we are using code based testing techniques, that writing unit tests to simply cover the code are not sufficient to ensuring software is completely functional. Therefore, it’s probably a good idea to use a combination of code and specification based techniques when writing unit tests.

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

PayPal’s Interesting Design Pattern API

PayPal is a massive online American banking and currency handler that allows users to transfer funds electronically. PayPal originally started out as a company that developed security software for handheld devices. This article describes the different design guidelines through the years of developing the API. All of PayPal’s platform services have been connected through RESTful APIs. REstful is an API that uses HTTP requests to GET, PUT, POST, and DELETE data. It is commonly known as the architecture style for designing networked applications. We have learned that, through design patterns, we can optimize and organize our code in efficient ways to make later implementations of other objects easier. I chose this article because it is another look at practical implantation of design principles for large businesses.

From the article, we can see that the basic principles for PayPal’s design foundation are very similar in what we are currently implementing in our code. Some of the principles include that are discussed in the article are Coupling, encapsulation, stability, reusable, contract-based, consistency ease of use, and externalizable. Since these APIs are developed with consumer business in mind, each of the principles follow a catered idea for each. For loose coupling, the services need to be loosely coupled from each other. This makes it so that components in a network can work together, but do not heavily rely on each other. Encapsulation is also important in order to group certain attributes together. This makes it so that we can restrict direct access to certain part of an objects components. The stability principle important in that we need to make the program stable. The code should also be reusable so that it can be used across multiple different instances and by different consumers and users. This is important for team collaboration and organization as well because if multiple people can understand where an issue is occurring, it can be solved a lot faster. For contract-based functionality, it needs to be shared using a standardized service. This makes it better to create a standardization because it loops back to the reusable principle and makes accessibility more seamless. As for ease of use and consistency, these both work hand in hand because since the service needs to follow a specific set of rules and attributes, it also needs to be easy to create for consumers. The last design principle is externizable, which requires that the service can save and restore the contents of its instances.

I learned that these design principles are interesting because they seem to be a great tool to use when designing a program because it offers fundamental guidelines for optimization. I expect to apply these principles in my future practice by remembering the importance of how code should be organized to make it accessible to the consumer and to the programmer.

Source: https://www.infoq.com/news/2017/09/paypal-api-guide

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

Acronyms to Remember

Source: https://blog.codinghorror.com/kiss-and-yagni/

This week’s reading is on KISS and YAGNI by Jeff Atwood on Coding Horror. Jeff touches upon and shows enthusiasm towards effective practices of KISS (Keep it simple, stupid!) and YAGNI (You Aren’t Gonna Need It). He mentions that just because you learned something complex that could be applied to your current project, it doesn’t mean that you should implement it when there is a more simpler option available. That is the idea of KISS. Lastly, he mentions that developers should follow YAGNI to combat the mindset of implementing solutions that you don’t need currently.

These two topics about KISS and YAGNI are very interesting because of how people are usually taught to think but when applied to programming, it doesn’t help but make things worse. Choosing to read up on this blog, allows me to see how more experienced developers feel about those who do not understand or value the two practices. Also, this is related to smelly code as it will help fight against dead code! In this case, I can feel that it is indeed a wise choice to pick-up KISS and YAGNI early on. Although, I have yet to write much programs that needed complex solutions. I do remember situations where my implementations were much longer when compared to other students, which could be a result of lesser understanding upon certain fundamental topics or lack of experience. Example being, the other student’s implementation of a loop for a solution is much shorter but does the same thing as my longer loop. It’s not exactly KISS, but it does show that sometimes things can be done in a simpler way.

Overall, understanding or knowing either practice will help save time when it comes down to getting things done. By knowing YAGNI, I will not implement things I don’t need until it is needed. By polluting the code with unused implementations, it will most likely create complications for later functions when it is used. However, if I don’t need it by then, the time spent creating the implementation for the future would be wasted time and not saved time. Then we have KISS which is rather straightforward, but should be a clear reminder that it’s when you can keep it simple, not always keep it simple. These two concepts will help me keep the code clean, and maintainable to a point where implementing newer features will not be as frustrating as when you work with smelly code.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

The Factory Pattern

Today I read a blog called “Creational Design Patterns: Factory Pattern”. I chose this because I was interested in furthering my understanding of the Factory Pattern, which we recently learned in class. The blog talks about how it is a creational design pattern, which means it deals with object creation. A good creational design pattern makes objects for a specific use; which is what this blog talks about. The blog describes the differences between the factory pattern (which is what this blog is discussing) versus the simple factory pattern as the factory pattern being a more complex version of the simple factory. The factory pattern has ways to abstract underlying classes from their superclasses. The blog uses a real life factory as an example to give the readers a way to understand the process. The factory is used to make objects for a user, without the user having to care about the internals of what happens in the factory. Basically, all the user has to do is ask the factory to make the objects, and the factory already has the instructions to make the object inside; relieving the user from having to feed the factory instructions on how to make the object. Another good thing about this point, is that now the factory can mass produce the objects. Say the user wants to make 100 objects from the factory. Instead of the user having to feed the factory instructions on how to make that same object 100 times, the user only has to tell the factory to make them 100 of the object, and the factory will do the rest.

I learned a lot from this article. I believe that it helped me further my understanding of the factory pattern. Why write the same code over and over again if you don’t have to? The example pointed out in the article is authors versus publishers. They point out that there are many different kinds of authors and many different kinds of publishers. Despite this, both authors and publishers of all kinds perform some of the same tasks, that being writing or hiring a writer, etc. So rather than having the same methods for each type of publisher and each type of author while overriding the rest to suit the specific author/publisher classes, we can take these generic “standard” classes and abstract them into factories that each type of author/publisher can inherit from, while each author/publisher class at the individual level will still have its own methods that are specific to that class. This will help me understand what I’m doing the next time I try to implement the factory pattern. I learned that I don’t have to repeat code over and over between classes, but rather I can just pull it out and make it a factory. I think it should be used whenever possible. It advocates for clean code, which is key to good programs.

 

Here’s the link: https://airbrake.io/blog/design-patterns/factory

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Post #4

As we are heading into our discussion of Decision-Table-Based Testing, I thought it would be a good idea to get some insight on what it’s all about and what its relevance is in the field of software testing.  Interestingly enough, I found an article about it on the International Software Testing Qualifications Board (ISTQB) website.  To become a certified member of the board, one must be knowledgeable in the use of Decision-table based testing techniques.  As I head toward graduation, I am always pleased to know when the material being covered in class is relevant and useful in the industry.

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

The Importance Of Clean Architecture

In Episode 68 of the CodingBlocks podcast,  they talked about the latest book, Clean Architecture by Robert Martin (colloquially known as Uncle Bob).  In the podcast, they explained the benefits of a clean architecture and why it matters. They said that the benefits of a clean architecture is that it can minimize efforts when it comes to adding features to the program.  Their functionality is maximized and changes are easy. It can reduce the number of people needed to write the software and adding features. They also added that there is no difference in design and architecture when it comes to a program. That the architecture should be incorporated into the design as well.  Throughout the podcast, they keep using the analogy of the Turtle and the Hare. They quoted that in the book, Uncle Bob added that “the only way to go fast, is to go well”. I think that this is a really good quote. Often we are bounded by the due date or time. In the podcast,

Also, in the podcast, they also said that “coding is easy, but managing our code when new features are added is the real challenge”. They said that maintaining cleanliness is better than cleaning it after the problems are piled up. Michael also talked about how sometimes, they say that the developers are not working. Which isn’t really the case. The problem lies in the architecture of the product since it does not support the changes that the product manager or client wants. They also talked about how sometimes company X comes to the market first but company Y is more successful because they were able to add more features faster than company X.

They also tackled the problem of rewriting the code, which most of us think would be the solution to the architectural problems. They said that rewriting is not the answer. Most of the time, we would rewrite the program to fix the problem. You will feel good about yourself when rewriting it since you are doing it really fast. But still not thinking about how to solve the architectural problem of your program. They said that the quality of your products should be taken seriously. Since developers are constrained by time most of the time, they forget the risk that are involved by being “fast”. Sometimes unit tests are not done and the code is not reusable anymore.

I chose to listen to this podcast because I wanted to learn more about Software Architecture and what are the benefits of having a good architecture versus just having a code that works. I  actually questioned Dr. Wurst about this, having done his first assignment for us. I asked him why we needed a better architecture even if the amount of classes in the program looks like a cluster. After listening to this podcast, it finally makes sense to me now. A product that have a better architecture is easier to change or add programs. In the long run, a better structured program is better and would be easier to manage than a program that is done “fast but not well”.

From the blog cs-wsu – Site Title by csrenz and used with permission of the author. All other rights reserved by the author.

Thoughts on “Deeper Testing (3): Testability”

In his article “Deeper Testing (3): Testability”, Michael Bolton defines the testability of a product not only in terms of how it can be manipulated (although that’s one of his categories), but as “a set of relationships between the product, the team, the tester, and the context in which the product is being developed and maintained”.  He breaks this into five somewhat overlapping regions:

  • Epistemic testability — how we, as testers and developers, find the “unknown unknowns” related to the product.
  • Value-related testability — understanding the goals of everyone with a stake in the product and what they intend to get out of it.
  • Intrinsic testability — designing a product to facilitate easier and more meaningful testing.  This includes the ability to manipulate and view the product and its environment.
  • Project-related testability — how the testing team is supported by and supports other teams or team members attached to the product.
  • Subjective testability — the skills of the tester or testers.

Bolton then details how he thinks a tester on an agile team should operate: by bringing up and advocating for the testability of the product, and trying to keep the growth rate of the product sustainable in relation to testing.

As I learn more in the course, I find it increasingly important to understand not just how we test, but why and in what context.  Bolton’s article is especially helpful in understanding the context, and that is why I chose to write about it.  The article highlights aspects of the environment that surrounds a product, and the ways that those aspects contribute to or detract from the feasability of testing.  It also speaks to a tester’s role in an agile team, which is in practical terms useful to know about as many companies use some form of agile development.

With any resource I find in relation to my coursework, I look at what I can take away and what I can apply in my life (sometimes not limited to software development or computer science).  This piece gives me a better understanding of how to begin testing a product — not by writing test cases, or even determining the optimal testing tools to use, but by looking at the bigger picture.  I need to ask myself what I don’t know about the product, how it is going to be used, how it can be designed (or was designed) to facilitate testing, how I as a tester can and should engage other team members, and what skills I have that can make testing easier or what skills I need to hone that I don’t already possess.

Article link. 

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

Object Oriented Programming(java)

I know many of you know much about Object Oriented programming. But still yet i wanted to give more details about it. To give you the real explanation of Object Oriented Programming  as being one of the main reason of choosing this topic.

Object-oriented programming (OOP) refers to a type of computer programming  in which programmers define not only the data type of a data structure , but also the types of operations functions that can be applied to the data structure.

Now in an object-oriented language, this program would instead be split apart into self-contained objects, almost like having several mini programs. Each object is representing a different part of the application and each object contains its own data and its own logic and they communicate between themselves. Now if that sounds like it could be a little bit confusing, the idea here is that these objects represent the way you would talk and think about the actual problem.

It’s meant to make thinking about your program easier. The objects don’t represent mysterious abstract ideas. They first represent things like employees, images, bank accounts, player objects, car objects, whatever actually exists in your program. So object orientation is an idea and it’s an idea that it’s supported in many languages. And for you it’s a shift to thinking about the objects in your program are not just the process. And while object-oriented programming can bring a lot of jargon into the table, there are really only a couple of terms we need to be comfortable with to move forward with it.

The first two terms we need to understand is the difference between a class and an object. And these two terms go hand in hand with object-oriented languages. A class is a blueprint. It’s an idea, it’s a description, it’s a definition. It describes what something is, but it isn’t the thing itself. It’s a well-defined idea, like say a blueprint for house. And classes will exist for different parts of your program. So if you are writing a restaurant review website, you might create classes that represent a restaurant and a review or a user.

Classes could also represent visual parts of your program, things like TextBox and Button and Window. And they can also represent invisible things like dates and times and anything that can be a well-defined idea. A lot of languages come with many classes already defined, even advanced things like VideoPlayer classes, and you can also define your own. Now all classes describe and define two things: Attributes and Behavior.

What are some things characteristics, its attributes, and what can it do, what’s its behavior. So in this case, let’s say we are describing a class to describe a person. We might say that the person attributes are name, height, weight, gender, and age, whereas the person’s behavior is walk, run, jump, speak, sleep. Think about it this way that the attributes are really your data, your variables. And the behavior is what can you do, your functions. And actually attributes and behavior in most object-oriented languages are actually described with other names, which is properties and methods.

These are the most common ways of describing these. But the class is describing these things in abstract. And what I mean by that is it says that a person has a name and it has a height, but it doesn’t say what the name is because the class is just the description of something. But just like there’s no point creating a blueprint if you never intend to make a house, there’s no point defining a class unless you’re going to make an object. So that’s the relationship between the two.

The class is the idea and the object is the thing itself. We create objects based on the class like creating a house based on the blueprint. Not only that, but you can create multiple objects based on one class in the same way you could create multiple houses based on one single blueprint. Now while there is a lot of jargon associated with object orientation, encapsulation is the key idea.

This the idea that classes are self- contained units that represent both the data and the code that works on that data, that we take our properties and our methods and we box them up, we encapsulate them. JavaScript is an object-oriented language. Although it is quite casual with it, there are some other languages where object orientation is very formal and you can do very little without thinking deeplyabout classes and objects. So while some languages like C are not at all object-oriented, if you’re working in Java, you can’t avoid object orientation in most modern programming languages.

From this topic i have learned a lot about Object Oriented Programming. , understand the difference between classes and objects.This will help me better understand any project given to me in java. I know now most of you have gotten the understanding of Object Oriented Programming.

 

 

 

 

Link to the site ::

https://www.edureka.co/blog/object-oriented-programming/

And

https://www.lynda.com/JavaScript-tutorials/Foundations-of-Programming-Fundamentals/83603-2.html?utm_medium=viral&utm_source=youtube&utm_campaign=videoupload-83603-1201

 

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

Making Testing More Effective Through Increased Testability

While there are few people who would would argue that testing is easy, it also should not be prohibitively difficult. The difficult part in testing software should be in deciding what to test, not how to test it. In a post from late September 2017, Michael Bolton describes how important testability is in the creation of a stable project with less risk of bugs at the time of delivery. If releasing a project untested or with insufficient depth of testing sounds risky to you, you are in good company. Making testing easier, known as increasing testability, allows for more thorough testing and (hopefully) a more polished, bug-free finished product.

Bolton describes testability in terms of visibility and controllability. The examples that he gives for visibility are log files and continuous monitoring. For controllability, Bolton cites application programming interfaces or APIs as the most common method for the easy manipulation of the product. An important takeaway from the post is that while it is certainly helpful to the tester if a product has things like log files and an API, this is not all that testability encompasses. Bolton presents the idea of testability as a set of relationships between multiple elements in the design process including the product, the tester, the development team, and the development environment. The overall testability of a product is a result of the complex interactions between all of these people and things involved.

The first category that Bolton mentions is epistemic testability. It is impossible for a tester to know all of the bugs in the code before performing any testing. If this were the case, there would be no need for software testers at all. The act of testing explores what Bolton calls a “risk gap,” or the areas in the project that the tester is uncertain about or unfamiliar with. Next, Bolton considers value-related testability, which refers to knowledge of what the intended user of a program is looking to gain. Understanding what is valuable to others allows a tester to focus his or her efforts where it will have the most significant impact. Intrinsic testability refers to the product’s ability to be easily understood by the tester. If a program’s behavior is easy to follow and its state is transparent to the tester, he or she will have a far easier time properly testing it. Since most projects are assigned to teams of people in many different positions, with different tools and knowledge, access to these people and resources is essential for project-related testability. Finally, subjective testability refers to the skills of the tester or testing teams matches the requirements of the project.

Bolton’s more literary definitions of testing were a welcome change from the testing material that I’ve read online and in text. Bolton seems to focus more on the people and the environment that the testing is being conducted in rather than on what specific tests are used. I think that as a student, many of the points that he makes are important to carry with me into any potential professional positions. Evaluating the testability of products through Bolton’s methods will allow me to better manage risk and deliver products with fewer bugs.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Turning the Big Ball of Mud into Modular Code

What Konrad Gadzinowski describes in the opening paragraphs of his post on “Creating Truly Modular Code with No Dependencies,” the “emotional rollercoaster” of developing software, is something that I’m sure anyone who has ever written a program has experienced. I certainly encounter this each time that I’m writing code for a project, whether it is an academic project or a professional one. Eager to begin a project, I often dive in and begin completing the simpler parts first. During this time, it seems that progress moves very quickly. After all of these easy, simple pieces are done, however, progress seems to slow or stall. As the requirements become more complex, I often find myself going back to previous code and rewriting things so that they integrate more seamlessly with the new element that I am adding. This problem is what Gadzinowski describes as the “big ball of mud.” Gadzinowski provides Apache Hadoop as an example of a program with the ball of mud interdependencies that slows further development and makes tracing the source of bugs more difficult. In the image below, each class is represented as a point on the outside of the circle, and the lines between the points are representative of a dependency.

(Image source: https://www.toptal.com/software/creating-modular-code-with-no-dependencies)

With so many interdependent classes, I imagine that untangling the web to trace bugs in Apache Hadoop would be a nightmarish task. Gadzinowski offers a solution to the problem of the ball of mud, however, that seems like sound advice. His suggestion is to use the element design pattern when developing software. This modular pattern aims to create reusable pieces of code that are independent of other classes. This is done through the use of element classes and element listener interfaces. In this way, all of the required dependencies for an element are encapsulated within that element. Outside classes that wish to utilize the element are not concerned with the underlying design of the element, they interact with the element’s listener. Gadzinowski presents this as a way to increase the flexibility of the element, allowing it to, for example, output to any number of different external environments through an identical listener call.

While I was immediately willing to listen to the post’s advice after it described a miserable situation that I’ve encountered countless times, I think that reading Gadzinowski’s explanations and examples of the element design pattern has certainly made me a believer. I think that what makes him so credible is his willingness to acknowledge the value in initially jumping into design without worrying too much about the big ball of mud that you may be creating. While this may not be the solution for a final release, it can get the ball rolling and allow for the element pattern to make your code more reusable and stable for production releases later on. I will keep Gadzinowski’s advice in mind the next time that I begin to worry that I have too many interdependent classes to make my classes reusable or easily maintainable.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.