As I take another step towards Software Quality Assurance Testing. I start to think and learn about how would I write a good unit test. That lead me to a podcast about “Clean Code – How to write amazing unit test” by Joe Zack. This podcast does a very good job on explaining the idea of clean code and also about how to write amazing unit test. This podcast also touches Test-Driven Developing.

The blog first starts out talking about a few interesting things however unrelated to the topic it finally gets into the topic 17 min into the podcast. For this blog I am only going to touch on the clean code part of the podcast to hear the full podcast please click on the following link https://www.codingblocks.net/podcast/how-to-write-amazing-unit-tests/#more-2483 otherwise…

The podcast mentions the following things about clean code:

There are a few problems with keeping test clean. For example, keeping test clean could outgrow your prod code and become unmanageable. However, there are more problems with having dirty code. Such as when/if code changes the test must also be change causing double work and harder to change. If test is extremely dirty it could become a liability.

Clean test is important because it keeps all test code readable, simple, clear, maintainable, and reusable. When you have tests it makes it easier to change code and less scary. A clean test makes it easier to improve the architecture.

A great way to have a clean code is by using the “Build – Operate – Check Pattern”. Which stands for building up the data, operate on the test data, and check by insuring that the operation yielded the expected results. Test should be written in a specific way so it will be able to be used in different testing platform. Another way to have clean code is to only have one assertion per test. Since, it makes the test easier to read. Although sometimes using multiple assertion is necessary and more beneficial to do so. Clean code can also be achieved by making sure to have a single concept per test. This idea is actually more important then having a single assertion. That is because it makes sure to only test related things, instead of un-related items.  A good general practice to follow for clean code is to remember “FIRST”. The F in first stands for Fast, meaning a test should run quickly and be fast. The I in “FIRST” stands for Independent, meaning each test must be independent. The R in “FIRST” stands for Repeatable, meaning test must be repeatable in different environment without the need of infrastructure specification. The S in first stands for Self-validating, meaning a Boolean output or either true or false is required. The T in fast stands for Timely, meaning a test must be written in a timely manner particularly before writing the production code in order to ensure they are easy to code against.

To sum this up practicing clean code is a very good idea to practice. From the testing to the code production clean code has more benefits then not. It is important to create unit test in order to be confident when needing to change the production code. Over time this practice will prove to be more beneficial since it allows improvements to be flexible and maintainable.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

As I take my first step towards my journey in Software Quality Assurance and Testing I dive into Unit Testing. After searching the web found a really good podcast named “Unit Testing With Test Driven Development” by Beej Burns this podcast is about Unit Testing and focuses most on Test-Driven Development (TDD). I will be using this podcast to help me write this blog.

In the podcast they had two guess John and Clayton. They went on the podcast and talked about their book ‘Practical Test-Driven Development Using C# 7: Unleash the power of TDD by implementing real world example under .NET environment and JavaScript’. I personally have not read this book. According to the podcast this book is meant for Software Developers with a basic knowledge of TDD. This book is intended for those who wish to understand the benefit of TDD. This book is beneficial for individual who know C# basic since all the examples are in C#.

The Following Q&A are the Question asked in the podcast and the guest answer. The answer I am writing are summarized in my own words but originally derived from the guest on the podcast. Also I am not doing all the Q&A just the ones I found interesting and liked how the guest answer the question. If you want to hear the original question and answer visit the podcast site: https://completedeveloperpodcast.com/episode-140/, Lets start.

What is Unit Testing?

Unit Testing is the ability to test in isolation. That is to simply test an application without affecting the rest of the other test.

Why is Unit Testing important?

We use unit testing to make sure each unit performs as intended. Unit testing is important because it minimizes the risk of error in your software, but it also forces you to have better code structure. It also allows major changes in your code to happen at a lower risk. Another reason it is important is because it allows new developer to understand your software structure.

*Note that naming convention is very important so developers can understand what is being tested.*

What is the point of Test-Driven Development (TDD)?

The point of TDD is doing the right thing without making a mess. That is short iteration cycle reassuring that you and your application are doing the right thing.

According to one of the guests when writing Test-Driven Development there are 3 stages/steps:

• Red cycle to see test fail
• Green phase when you make the test pass
• Refactor production code and test code.

The idea of TDD is to build the test before the code.

Other benefit for TDD other than code in an organized level is:

• Reduces the overall bugs and make bug resolution quicker.
• Less down time.
• Better requirement
• Can find problems with just running the test which it shows where code went wrong.

What are some of the things people get wrong about unit testing and TDD?

Testing your test too close to your implementation. “Test should represent the business rules not how you decided to implement the business rule. That way when you go and change stuff later on like the implementation. You want to refactor and remove thing into a different class. This doesn’t break what your test does because you will be restructuring how it is doing it”.

How do you manage complexity on a unit test, and how do you structure your overall testing projects?

“Form an overall method uncle bob (Robert Martin) suggest only having method that are five lines or less in size”. The guest that answer this question take Robert Martin suggestion to heart. He goes on and explains that if a method has more then five lines then he’ll brake it down into more than one method. If a class has more than five method then he’ll brake that down into more than one class. If a folder has more then five class than he’ll brake that down into more than one folder. If a project has more then five folder he’ll consider braking it down into more than one project. He goes on and say that he will do the same exact thing when testing except he doesn’t care much about the line length because most test case are usually 3-4 lines long. He has the arrangement where he set up the pre-content of the test and then have the action are 1-2 lines. These tests are pretty small to start with but within a test class he won’t have more than five things overall that he is testing within a test class, no more then five unit, and no more than five logical assertion which tends to reduces the size of any one thing within a test project.

What are some good practices you can use to make sure your test is maintainable on the long run?

• “Don’t forget to refactor your test, because your test suit is just as important as your production code”.
• “Remember you are testing small unit or small pieces that should have never enter connective dependency so that you feel comfortable substituting a mock, spy, or fake implementation. Be careful not to test your fake, mock, or spy.”
• “Where ever the code end that’s where the test should end”.
• “Make sure we abstract all third-party code”.

I will wrap this up by saying unit testing is a very important skill to have no matter what. It helps in creating clean code and reduces the risk of error. Unit testing allows software developers to make large changes in the software code at a minimal risk rate and it allows code structure to be understandable by new developers. One thing to note is when creating unit test and developing software you must make sure to have good naming convention. When developing software, its best to start with writing the test first.

My name is Yesenia Mercedes-Nunez and this has been YessyMer in the World Of Computer Science, thank you for your time until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

As I take another step towards my journey in software C.D.A. I dive into Design Pattern, where I will be focusing on one of the patterns known as Adapter pattern. While searching in the internet I ran across a blog called Design Pattern Explained – Adapter Pattern with Code Example by Thorben Janssen.  This blog talks about Adapter Pattern which actually is one of the many Design Pattern type. This topic is chosen because it was one of the pattern talked about in my Software Construction, Design, and Architecture class. Since the blog by Thorben Janssen talks about the topic related to a class discuss topic, I choose this blog to write about it and summarize its content in my blog. The content in the blog is about the Adapter Pattern of Design Pattern. I will give a summary of what the blog was about and what it explained from my point of view and understanding.

According to Thorben Janssen research on Adapter Pattern, there are two different version of it. The type that uses inheritance and the type that uses composition.

What is Adapter pattern?

Also known as wrapper, the Adapter Pattern is a software design patter that allows the interfaces of an existing class to be used as another interface. In software development the adapter pattern has the same concept of those in real life, for example phone adapters.  Meaning adapter patter are similar to phone power adapters in the sense that one adapter can be used with many different USB devices cable. Say your at your friends house and you have an i-phone USB charger cable but no power adapter, and lets say your friend owns an android and only has an android charger. He can unplug is USB android cable from his power adapter and hand you his power adapter for you to use with your USB i-phone cable so you’ll be able to charge your phone. An adapter is convenient because it enables incompatible objects or devices to be used for the same purpose. The adapter pattern is also convenient because it allows you to use existing class or interface by introducing a new class that adapts between classes and interface without changing the existing class that is known as an adapter class.

In the blog “Design Patterns Explained – Adapter Pattern with Code Example” by Thorben Janssen he gives an applied example of the adapter pattern he referrers it as Brewing Coffee. I highly suggest you to click on the title so you can check out the example and see how he implements the adapter. I will end my blog here and let you do your own research on adapter pattern.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

As I take a step towards my journey in Software C.D.A. I am told that for my first task I must find a blog related to the class topic. The blog I chose was “The Solid Principles of Object Oriented Design” by Joseph Smith. I chose this blog cause it’s about one of the Object Orientated Design Principle. A topic that was supposed to be cover on the first day of class, but was not covered since we ran out of time. This blog was short simple and direct to the topic, hence why I chose it. The content in the blog is about the S.O.L.I.D. Principle of Object Oriented Design. I will give a summary of what the blog was about and what it explained from my point f view and understanding. It goes as follows:

There is about five Object Oriented Design Principles known as SOLID. This SOLID principle is used by Software Developers to help them successfully develop applications that are clearly workable.

SOLID stands for the following:

S)  SRP – Single Responsibility Principle.

• This means that a class only really need one duty, and only one motive to change.

O)  OCP – Open Closed Principle

• This means that a class needs to be open for extension, and closed for any changes.

L)  LSP – Lisko Substitution Principle

• This means that the child class must allow the parent class to be interchangeable with it. Meaning the child class can inherit from the parent class by utilizing a copy of all or sum of its objects and change what’s within the object to what relates to the child class.

I)  ISP – Interface Segregation Principle

• This means a class is not required to use any methods it does not need. This is possible through Interface Segregation by taking the larger interface and splitting them into smaller ones, all the way until a class implementation of the interface. Once that happens it only will have relevant methods.

D)  DIP – Dependency Inversion Principle

• This means that high-level of modules are independent of low-level of modules, but both are dependent of abstraction. However, abstraction is not dependent on details and vice versa.

Then the blog finish by saying it will continue with more in-depth information of these principles the next few weeks. It also suggests we go on Wikipedia if we seek more information or detail on the subject so, I did. Well the reason mainly being that I was unclear on the Dependency Inversion Principle. I had to go on Wikipedia to see how it’s explained on that site and if I could understand the concept better. Okay, let’s just say I did so the definition I place on the DIP section was obtained from Wikipedia and not the blog itself. Now, other than that part of the blog everything else was understandable and explained the principle. I found the link to the Wikipedia page useful. I like how the Arthur only focused on the SOLID principle because it’s a pretty big subject and very easy to get lost and confused. This blog has taken me on the right directing to understanding one of the subjects related to the class Software Construction, Design, and Architecture (CS-343). I honestly liked this blog and it made me realized I know some of the topic since it has been covered in past CS classes. I am eager to learn more as it will help perfect my skills.

This has been YessyMer in the World Of Computer Science, thank you for your time until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.