Hi my readers. Welcome back to my blog.  In this blog post I am going to talk about an interesting pattern called “Use Your Title”.

Most us, who have worked in big companies and most of you who will in the future, are gonna have a FANCY title at your job. Sometimes even the person itself will get confused by its own title as at the beginning might not describe well what it means.

The best advice given by the authors for this pattern is: “Don’t allow your title to affect you! & Don’t be fooled by an impressive title!” It happens a lot nowadays that people have to explain what they really do because not everyone is aware of what a job title might be and what are the duties and responsibilities. There are also a lot of other cases where people misinterpret the job titles. My job title in my company is Support Engineer. and when some people would hear the name Support they automatically told me ” So you like talking on the phone with customer huh?!” That’s where I had to explain what my real position was and what was I actually doing. As I come from Albania, at the beginning I used to ‘blame’ on the company for giving me this title, but later on I realized it was the people who were to blame.

As you might know by now, I am graduating this May with a major in Computer Science and Software Development concentration. While having a conversation at my office with my teammates we all agreed that our titles were a bit too much as we hadn’t graduated as Engineers but developers. However, we all like using the fancy title.

The other side of the coin is where you have such a high job position and your job title doesn’t fully express much about it until you say what you actually do.

In both cases, the most important thing is to explain what you do with your own words and not the title, fancy or not. It is always good to have a written definition of what you do and what your duties are as you might never know who you might come across to.

Hello dear readers. Today we are going to talk about SOLID, the first five principles of the object oriented design.

S.O.L.I.D is an acronym for the first five object-oriented design principle. When these principles are combined together, it makes it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid easily refactor code and are also a part of the agile or adaptive software development. SOLID stands for:
S – Single responsibility principle
O – Open/Closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion principle

Single Responsibility Principle states that a class should only have one job, only one reason to change. The reason why we should use SRP is because it makes your software easier to implement and prevents unexpected side-effects of future changes. Another benefit of this principle is that classes and software components that have only one responsibility are much easier to understand, explain and implement than the ones that provide solution for everything.

Open/Closed Principle states that objects or entities should be open for extension but closed for modifications. Using this principle prevents situations in which a change to one of your classes also requires you to adapt all depending classes.

Liskov substitution principle states that every subclass/derived class should be substitute for their base/parent class. To achieve that, your subclasses need to follow the following rules: 1. Don’t implement any stricter validation rules on input parameters than implemented by the parent class. 2. Apply at the least the same rules to all output parameters as applied by the parent class.

Interface segregation principle states that a client should not be forces to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use. By following this principle, you will be able to prevent bloated interfaces that define methods for multiple responsibilities. You should avoid classes and interfaces with multiple responsibilities because they change often and make your software hard to maintain.

Dependency Inversion principle states that entities must depend on abstractions not on concretions. High-lever and low-lever modules also depend on the abstraction. This design principle does not just change the direction of the dependency, it also splits the dependency between the two levels by introducing an abstraction between them.

Hello dear readers. Today I am going to talk about Unit Testing. I believe most of the people are pretty familiar with it, but for those of you who are not : Welcome to What is Unit testing and why to use it!
Unit testing is a testing process where the smallest part of a program or an application are tested individually. A unit can be almost anything you want it to be — a line of code, a method, or a class. Generally, smaller is better. Smaller tests give you a much more granular view of how your code is performing. There is also the practical aspect that when you test very small units, your tests can be run fast; like a thousand tests in a second fast. Unit testing involves only those characteristics that are important to the performance of the unit under test. This encourages developers to modify the source code without worrying about how such changes might affect the functioning of other units or the whole program. Once all of the units in a program have been found to be working in the most efficient and error-free manner possible, larger components of the program can be evaluated by means of integration testing.

Unit testing is performed by using the White Box Testing method. When creating Unit test we should keep in mind not to create test cases for everything. Focusing on the tests that impact the behavior of the system is the most important. Another issue that is usually very common in software testing is debugging and unit testing makes it easier. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/weeks/months need to be scanned.

Unit testing also increases the confidence in maintaining/changing the code. When these unit test run after the code is changed, will be able to promptly catch any defects coming from the changes made.

To be honest Unit testing is probably my favorite way of testing. Of course, as a tester Unit testing is not efficient for lots of code and other ways need to be consider. However, the reason why I like Unit testing is because it helps you figure out where the defect is in the code. The changes of a defect persisting are higher when not using a unit test and if you try to fix it you can break something else.  Also, it is good to write tests before trying to fix it because if you fix it right away you will be lazy to write tests anyways. And keep in mind test coverage has to be as high as possible! ALWAYS!