Expose Your Ignorance

This pattern is one among the many which I have drawn so much knowledge and think will go a long way to help me grow in my future employment activities as far as software development is concerned. Educationists will tell you that learning is a gradual process and I know it’s not going to end in the classroom when the time come and I am out of the classroom to the field to face the world. This pattern has just reaffirmed that learning is still going to take place afterward. It is really hard as David H. Hoover admitted to say you don’t know when they expect you to know what they are asking you to deliver. But for my own good I will not be tempted to give quick answers to questions that will put me in trouble later on. Again, this  pattern has also given me the idea that as an apprentice, my goal is not to become an expert but that will come naturally as I go the journey and explore deep into an interesting areas of  learning.

I strongly agreed with the point that when your answer questions, you become clarified of your own knowledge. This is true because, anytime I help someone do something or explain something to someone, I will never forget that subject again; that is stick in my head forever. I used to be shy to speech in public even if I know the answer but as I grow and become more familiar with difference group of people, things began to change. From then,  anytime a question is asked in the mixed of people, I always try to be first to respond  to it if only I have an idea of what is being asked  because I know how it help me in understanding the scope of my knowledge better.

I have been trying to cherry pick these patterns but I realized going through all of them will help me more because, they are interconnected. So far, with what I have learned, all the patterns has something unique that I think if carefully adopted will go a long way to help me deal with all the problems I will be facing as an inexperience apprentice.

Refactoring

After reading and doing factory pattern design, I was still not sure why we used it and its purpose in a code; I decided to do in-depth reading and also post this blog to outline the main ideas gotten from this reading.

First of all, what is refactoring? Refactoring is a name given to a collection of small individual learning techniques for improving code that has already exit. It implies the code has already been written, it is working and you are not changing it functionality. The purpose of refactoring is not to break down code and rebuild it. It is to improve on the exiting code for more clarity.

Again, what do we get for refactoring code? Refactoring is used to improve code design to make it easy to understand and extensible.

Besides, Refactoring also makes it easy and quicker to create complicated systems.

Refactoring makes code easy to read and eliminate duplication and make modification easy and minimizes complex conditional logic.

Refactoring removes excess code so that it is easier to understand and modify.

In other words, one of the main objectives of refactoring is to remove bad smell. Bad smells are common design problem and they are usually unclear, complicated or duplicated.

behavioral vs Structural Testing

Behavioral vs. Structural testing

After thoroughly reading of the chapter with the level of testing, I have seen the important of one understanding the difference types of testing, how to use them and more importantly what time or stages you are required to use a particular technique. In this regards, I am writing this blog to basically outline the major differences between behavioral testing and structural testing techniques. In my earlier postings for the level of testing, I tried to capture all the testing techniques. I have also talk of dynamic verse the static testing and it is now time to look at behavioral and structural testing in comparative perspective.

Both structural and behavioral testing techniques are used to ensure adequate testing.

First and foremost, Behavioral testing which is also known as functional testing is a kind of testing where the functionality of a software is been tested. This type of testing is often referred to as black box testing. Functional testing basically is test that happens during implementing requirements and design specification.

Also, Functional testing usually cares about only the results but not processing because the tester does not have to know anything about the code or program.

Structural testing however is a testing technique which is based on the internal structure of the program or code. Structural testing basically analyses the code to verify if there are errors in the design process. Structural testing which is often called white box testing is concern with both the result and process because knowledge of the code is very important; we need to understand the design code. This is a stage where design requirements and algorithm are discussed. White box testing technique often get work done and can be run every time part of the code changes, allowing issues to be resolved as quickly as possible.

The main objective of the structural testing technique is to ensure that the functionality of the code is as required and the design is readily acceptable to be implemented in the real world.

Again, I am inspired a lot reading this chapter and writing this blogs as they enables me to do in-depth reading into the topics and more to the point understand the various levels of testing, their unique terminologies and differences as a whole. I know very well that I did not only understands how and when to use a particular testing technique but it is also going to help me save time in my future testing as I will know in the fly which technique to use.

Reference:

https://www.seguetech.com/the-four-levels-of-software-testing/

http://www.coolinterview.com/interview/10760/