Category Archives: Blog Post Reviews

The Flavors of Software Testing

Recently I took a final in my Software Quality and Assurance class. While I think the final went relatively well there was one question that has been haunting my dreams, hiding in every dark corner of every dark room I find myself in. The question was one so simple yet for reasons unbeknownst to me, I froze. A concept that, at a former point in my life in the not so distant past had been second nature to me. The question was “What is the difference between static and dynamic testing?” Since I failed myself and my professor on that test I felt like I should use this blog as a way to freshen up my understanding of both types of software testing.

I found myself seeking elder guidance on the matter and landed at the doorstep of Lakshay Sharma on the ToolsQA blog. A very short and simple read later I felt the rush of knowledge come back to me and I feel comfortable that I can talk on the matter of static vs dynamic, white vs black box testing. The blog made it very easy to understand the concept because it is laid out in a simple format: the first section explains static testing, and the second black box. After both sections there is a small graphic that shows the differences between the two. So, what is static testing anyways?

Static testing refers to software testing that is done without running the program. This testing is also called white box testing and is done prior to running the code and can help sort out a multitude of issues within the program. Things such as code structure, and code pathing can be tested at this stage and without the use of unit tests. This type of testing is beneficial because it forces developers to take a step back and review the code they are writing. If you’ve ever gotten into a groove while programming and then taken a step back to see the mess you just created you would know why static testing is such a good tool to have in your software testing tool belt. Static testing is full about preventing errors in the first place, and as the age old saying goes: an ounce of prevention is worth a pound of cure. While that prevention is great, in the event that you do get sick, you are going to want that cure as fast as possible and as strong as possible to get you back on your feet. This is where dynamic testing comes in.

Dynamic testing is the act of testing code while its running. Although while creating dynamic tests you may be able to see the code, dynamic testing falls under the umbrella of black box testing because the tests themselves do not care about the inner workings of a program. Dynamic testing tests behavior such as input/output. The good thing about black box testing is that tests can be written prior to developing code and give programmers an easy way to determine if a program is working as intended. Dynamic testing requires more time to set up than static since it involves actually creating test cases.

Just as life is made up of thesis and antithesis and one cannot exist without the other, static testing and dynamic testing go hand in hand and to use only one is to cheat yourself of the best possible work you could be producing.

 

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Are you Mocking me?

The idea of mock objects used for testing makes me very excited. After struggling through an assignment on mocking in the very class I am writing this blog for, my excitement started to waver. Luckily I was able to get everything working after messing with gradle dependencies and the locations of files within the project and it was really a joy to see just how powerful mocking could be. I decided to look at mocking in greater detail for this blog post, because while the assignment we did in class did set up a good introduction, I feel like most of the assignment was spent setting up mockito, a really handy java mocking framework.

I found a really thorough article about mock testing written by Michael Minella (over a decade ago!) over at Dzone.com. While this article is ancient in terms of how quickly technology changes, I feel like all of the information given is still very relevant today, even if frameworks have changed a bit since then.

In the real world it is almost impossible to program without having to use dependencies. Mocking is one way to make sure that tests are only testing what needs to be tested, rather than testing the method in question and all of its dependencies. It allows you to create “Mock” objects that return desired outputs for their methods since tests should assume that any other methods that need to be called are working as intended. To reiterate what was said in the article, If a method has a dependency that returns an ArrayList, you most likely aren’t testing that ArrayList works as intended. You should assume that it works and test the method under that assumption. Mocks are proxy objects that only return what is necessary, eliminating any potential issues where the dependency could have an issue that would muddle the usefulness of the tests.

The article doesn’t go into detail about any specific frameworks but does talk about the how exactly the different types of frameworks work. According to the article, Mocking frameworks that use proxy objects, objects that are injected into the test file without modifying any other code, are far more popular than any other types of mocking frameworks.

This article is a must read for anyone looking to start using mocking in their unit tests. I feel like dealing with dependencies in my unit tests is something that I find myself struggling with and Mocking is most certainly a good solution to that.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Should Tests Drive Development?

After spending many hours reading about the benefits of TDD, Test Driven Development, I thought for sure that anyone attempting to program any other way was putting themselves at a huge disadvantage. I mean, who wouldn’t want to get work done faster, cleaner, and with more test coverage? While searching the internet for information about TDD I stumbled upon Robert C. Martin, one of the founders of Agile and writer of Clean Code‘s, blog. On his blog he wrote a post about a study done on TDD that actually proves that TDD brings no benefits into the workplace. As someone who read both Clean Code and Clean Coder I thought that Martin would disprove the study with an iron fist, yet that wasn’t the case.

Martin’s blog post was written in dialogue format which does make it pretty easy to follow along with his main points. Martin doesn’t outright deny the claims made by the writers of the study, rather he claims that their study wasn’t really testing two different ways of programming. The study had two groups work by programming in small chunks while one writes unit tests before, TDD, and the other writes their tests after, TLD, or Test Last Development. While it may seem like both of these ways of programming would yield massively different results there is an inherent problem with the way the study was carried out.

In order to program in small chunks, no matter when the tests are written, one has to think about the tests before writing the code. It is nearly impossible to know what a “small chunk” is for testing unless a test is already in your mind. This is the problem with the study. Both groups were essentially doing TDD except one group was writing the tests prior and one group was committing to the tests that would be written later prior.

The study shows that TDD doesn’t make you any faster or less prone to error than TLD, yet it seems like the two groups that were being studied were both doing a form of TDD, just one was using a less formal version. If there is anything that it seems one could take away from this test its this: writing code in small chunks, even if you aren’t writing the tests before, is the most efficient way to program. This study didn’t disprove TDD, rather it proved that one of the most important principles of TDD, writing code in small chunks, is extremely beneficial to all programmers.

One of my biggest issues when programming, and something that I find happens to me all to frequently, is I’ll have an idea for a way to solve a problem and I’ll chug away writing code until I think I have the whole problem solved. One “full send” later and a couple erroneous outputs and I’m lost as to what I should change in order to make my code passable. I feel like even if I am not using TDD completely when programming for things such as programming challenges, I should try and write in small chunks with the tests I will be writing in mind.

Overall a very fun read by “Uncle Bob” Martin. I am extremely glad I stumbled upon his blog because I enjoyed reading his books a great deal.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

The Great Pyramid of Software Testing

They all warned me that this was a horrible idea, yet here I am, guided only by the determination to find the uncovered truth lying behind the stone walls erected by our ancestors centuries ago. I walk across the endless sweltering sea of sand, my skin boiling and the contents of my canteen running dangerously low. I continue for what feels like an eternity in the direction I had estimated the pyramid to be in, although after days of walking I am starting to have my doubts. As the last drop of my strength gives way I find a small dune to rest on. Hours pass as I bake in the desert sun knowing that I may never find the truth I am searching for. I open my eyes to find Martin Fowler reaching his hand out to me silently expressing his infinite knowledge of the desert I find myself in. Fowler hands me his flask of water and I feel my energy and determination replenish and we walk through the desert speaking very little, yet I know now that we will find the Great Pyramid of Software Testing.

To anyone reading this, I am deeply sorry that you had to read that little prologue, but I mean, how could I not make a desert journey scene when talking about the software testing pyramid. Anyways, fluff aside, I decided to read a post that Martin Fowler made in 2012 that is still extremely relevant today. As I am taking a software testing class currently I thought it would be interesting to see where the type of testing we have been doing fits into the actual pipeline of software development.

In Fowler’s article he talks about the differences between low-level unit tests, high-level UI driven tests, and everything in-between. The pyramid has unit tests on the bottom, acting as the base and where the majority of tests should be. Then, just below the GUI driven testing, comes service layer tests. These are tests that are generally API driven that don’t suffer from many of the problems that UI driven testing has. Lastly, the tip is where the UI tests are, these tests can prove to be useful but have many drawbacks.

UI tests are the most brittle of the three types of tests as many times moving an element of the UI can result in having to refactor most of your tests. Fowler describes high-level tests as a second line of defense. This can prove to be useful because if a high level test fails it can expose underlying holes in your unit tests.

With test-driven development being so prevalent today with Agile frameworks, it makes sense that Fowler would recommend that unit tests are created whenever a high-level test exposes a bug as it makes it much easier to focus on squashing the specific bug that was found in the high-level test. Fowler also makes a case for always trying to use tests that lend themselves well to the type of application you are developing. If it is a javascript program it is best tested using a javascript testing framework like Jasmine.

Fowler’s article is filled to the brim with useful and topical information about testing. unit tests are the most flexible and powerful test type so it makes sense that anywhere a unit test could be used it should be. While the other two types of testing are less agile, they can provide benefits when usability is taken into account and only tests that make sense for UI level test are made.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Demystifying REST for myself

To preface this post I would like to say that this is the last blog post I will be writing for a little bit. I hope to return to this blog with a new outlook on the process of writing blogs and hopefully with more freedom in what I can post, the frequency and quality of posts will increase. In this post I have decided to do some research on REST in order to fully understand it so that going forth in my career I have a firm grasp on REST. Before reading this extensive article on bbvaopen4u.com about REST pretty much all I knew is that REST deals with http requests and http stuff.

First thing I learned when reading the post was that REST is more of a blanket term for any interface between systems that allows for the transfer and editing of data over multiple formats. This idea is so important because it vastly increases the scalability and functionality of products being created. It has become the standard in creating web applications and is used by most of the top sites such as YouTube, Twitter, and Facebook. The writer then goes into detail about the features that make REST special and why we all love it. A great feature of rest is the fact that everything is manipulated through the URL, keeping applications very uniform in how they access objects. They also talk about how it is a layered system which helps organize large applications. They then go into the benefits of using REST. Using REST separates the clients and the server which allows for scalability and ease of migration to other platforms. REST is also always independent of type of language being used which also increases options for migration and ease of development.

I enjoyed this read and while I feel as though it could have delved a little deeper into what REST is it was a quick easy read that helped me understand REST. Using REST in our assignments and project I had been emulating what I had seen without truly understanding what REST was. If you are like me and was having trouble grasping the concept of REST I would recommend reading this post.

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.

Music Composition and Programming are More Similar Than We Think

I consider myself a predominantly creative person as opposed to someone who thinks in a very mathematical and literal way. Most people would probably argue that I should be going to school for something along the lines of art or music but I’d argue that programming requires the same amount of creative prowess as both of those majors.

A user on DevDungeon wrote a post about this topic called Similarities Between Music and Programming. This article goes into detail about how the learning process in both music and programming is very similar. They talk about how most people feel like music and programming similarly are things that you are born with a natural gift for and can be difficult to learn. With music there is very much a mathematical science behind the music which can almost always be explained using the concepts learned through music theory. In music there are very many ways to get a similar result and all musicians will think of songs and have vastly different musical ideas. The same could be said for programmers. Many programmers can come up with vastly different solutions to the same problem based on how their brain solves the problem at hand. They also talk about how there is a hypothetical “stage fright” that occurs when just starting out in both fields. New musicians and programmers usually don’t want to share their work because it is very much an extension of yourself and if it is not up to your own standards it is hard to want to share what you’ve made. You can think of collaborating on a program with others as a band of sorts. If all members of the band aren’t on the same page then the outcome will most likely have many issues. They then go on to talk about how music and programming are very hands on and from day one should be taught in a hands on way.

I agree with almost everything said in this post. It was a very enlightening read because I have always taking a liking to the creative arts and seeing the similarities now it makes sense as to why I enjoy programming so much as well. I’d argue that programmers should learn music composition as it would help with the fundamentals of problem solving that are essential for programmers.

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.

Deep Learning AI Programmers Have Come to Take Our Jobs!

From the minds at Rice University comes a very interesting application for deep-learning AI. Bayou is an AI that, with a very small list of keywords, can produce usable blocks of code. It does this by scanning github and learning from all of the open source code on there. What does this mean for all of us computer scientists? This means that an era where AI may be able to aid us in completion of programs is on the way. For a long time this concept has been played with but never in such an efficient manner as Bayou. With other AI programmers sometimes the parameters you would have to enter to get a usable end product would surpass the program itself in length and complexity. While my title is very clickbaity I can guarantee that our jobs are safe for a very long time. This technology is only in infancy and for large programs that interact with many APIs and databases and such the need for a human to parse what needs to be written is still very essential. Bayou is more of a proof of concept that if built out even further can be very useful for speeding up the programming process.

In the post Turning deep-learning AI loose on software development, Jade Boyd makes many fair points about the ethics of Bayou. As programmers being so connected to the internet constantly has made it almost impossible to write programs from scratch. At any slight hitch we are able to search the internet and find someone else’s solution to a problem that we are facing. This point really proves that Bayou shouldn’t be seen as “cheating” rather that it is yet another tool that can give us examples of ways to solve specific problems that we maybe would have otherwise not given thought to.

I believe that applications such as Bayou are a step in the right direction. If we can get AI to write all of the simple parts of programs it would guarantee less simple errors and can also unify the format of the program. Programs can get extremely complex and Bayou wouldn’t replace us rather aid in saving us time and therefore money in the programming process.

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.

Crunch-a-Time me Captain (I just took a class on Design Patterns and Just Read That They are Wrong)

If that title scared you, I am sorry. This is the second post I am writing in a span of a couple hours and decided that this topic would prove to be a very interesting one to cover. While the post Rethinking Design Patterns by Jeff Atwood very openly claims that design patterns often cause unnecessary complexity and have turned much of today’s programming army into a mindless army of Gang of Four missionaries I believe it is a very delicate balance of both sides of the argument that is the solution.

In the post Atwood lays out the definitions (yes definitions!) of design pattern in order to get rid of any confusion about what he is referring to. There are two definitions because he is talking about the patterns created by the gang of four in order to solve typical solutions and also the general idea of designing a template for a solution one is faced with based on the circumstances. He also writes about the book that directly inspired the gang of four bible. This book is called “A pattern Language”, and is a direct inspiration for the design pattern book that succeeded it. This book outlines general ideas for solving problems rather than giving the reader templates to solve general problems. While the difference in these may be subtle, the latter cause anyone implementing an idea to have less of an understanding of the implementation and whether the chosen pattern is the best way to solve the problem at hand.

I feel as though the teachings I have received about design patterns has greatly influenced my understanding of coming up with solutions to problems. Before taking this class almost every program leading up to it was extremely complicated while solving relatively simple problems. Many of my programs were one trick ponies that if implementation had to be added would be in need of an almost total rewrite. After learning about design patterns I have the proper tools to increase how modular my programs are which is a huge step in the right direction. I feel like there are many cases where the gang of four design patterns are applicable and can be very efficient but for problems that don’t require a pattern it is important that we as programmers can recognize this and implement a simpler design to avoid useless complexity.

I will definitely be reading A Pattern Language soon because it seems like many of the ideas laid out in that book are extremely helpful in situations where I am tasked to program something that I can’t think of a design for. Thank you for coming to my Ted Talk.

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.

An Update on this Blog and also Cleaning Up House

I would like to preface this blog by saying that I am very sorry for the lack of content on here. Life can be overwhelming and this blog was put on the back burner throughout the semester. This being said I am excited to give my opinions on some really interesting content that I have been reading about.

The blog post I decided to write about for my blog post is aptly named “Clean, high quality code: a guide on how to become a better programmer”. I decided to research this topic a bit because while I feel like I have a good grasp on the technical side of programming I have trouble keeping my programs neat. This issue becomes very apparent when you decide to update a program you haven’t looked at in a month or so and it is complete nonsense that is almost impossible to parse no matter how much time you look at it. This problem is exponentially larger when others have to collaborate on projects with me and find it difficult to contribute to the giant ball of garbage I have artfully crafted with my keyboard. I long for the day where every aspect of my programs shine like a well polished stone and I am proud to add projects I have created to my resume.

The blog starts off with asking the very appropriate question “what is clean code?”. To which it replies with an image that genuinely made me laugh out loud. It illustrates that code can be measured in how many “WTFs” can be heard from others reading the code. While this is hilarious it also lies very much in truth. The less confusion others have while reading your programs the cleaner it is. The first half of the post is mainly outlining why clean code is good and why bad code is bad. It explains it extremely well using metaphors such as “leave the campsite cleaner than you left it.” After the post goes into detail giving tips as to how one should name variables and functions. Many of the ideas in the blog I have never given any thought to like naming functions verbs and naming variables nouns. While this is extremely intuitive I can guarantee that I have done the contrary which resulted in the use of functions being lost in translation. Interestingly enough the blog claims that having functions that are so clear in their intent that comments are unnecessary is how one achieves code nirvana.

Overall I’d recommend this to anyone who hasn’t taken the time to lay some base guidelines while they are writing programs. All of the information given in the post is very useful.

Image result for hoarder
Visual representation of my code before reading the blog

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.