Integration testing is the second step in your overall testing process. First off you will perform you Unit test, testing each individual component to see if it will pass. However, your testing process is just getting started and is not ready for a full system test. After the Unit test and before the system test you must run an integration test. This test is the process in which you combine all your units to test for any faults in the interaction between one another. Yes each individual unit might pass on its own but having them work together simultaneously in an integral part of the program.
These are the many approaches one can take to Integration testing:
Big Bang is an approach to Integration Testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang Integration Testing and System Testing? Well, the former tests only the interactions between the units while the latter tests the entire system.
Top Down is an approach to Integration Testing where top-level units are tested first and lower level units are tested step by step after that. This approach is taken when top-down development approach is followed. Test Stubs are needed to simulate lower level units which may not be available during the initial phases.
Bottom Up is an approach to Integration Testing where bottom level units are tested first and upper-level units step by step after that. This approach is taken when bottom-up development approach is followed. Test Drivers are needed to simulate higher level units which may not be available during the initial phases.
Sandwich/Hybrid is an approach to Integration Testing which is a combination of Top Down and Bottom Up approaches.
I think this part of the testing process is the most interesting. Once you have individually working components it’s like making sure the puzzle pieces fit.
The c4 model is a tool used by programmers to articulate their software designs in a translatable manner. Using this model a programmer should be able to communicate their design easily to those outside the professions, say a stakeholder for example, and also to their programming team. The model should have levels and using “abstraction first” the levels should show different amounts of complexity that overall allow you and your team to implement the data. A great example of the overview of the c4 model is to think of google maps and their zoom feature. If you are looking at a country and are zoomed out so that you can see it in its entirety, then you may only see the name of the country and what is surrounding it. Then if you zoom in a bit you may see the states that make up the country. Zooming even more, you can see the cities, towns, and you may zoom all the way in to a specific location and see what is there. This allows the viewer to utilize the abstraction to avoid being overloaded with information and instead look at the data in layers of complexity.
C4 models are implemented to represent the three levels of design. The three levels are known as:
“System design refers to the overall set of architectural patterns, how the overall system functions—such as which technical services you need—and how it relates to larger enterprise contexts. System design is shown in a Context diagram.
Application design refers to the combination of the services that are needed and how to implement them. Application design is shown in a Container diagram.
Service design refers to the patterns and considerations that are involved in implementing specific services. This type of design starts to emerge in a Component diagram”.
Relating these three levels of design to the google maps example starts to make things clear. The system design would be the view of a country in its entirety without too much detail, or in other words the big picture. Application design is a bit zoomed in and could show the states that makeup the country and helps to show the relationship between data inside the big picture. Service design would be the specifically zoomed areas where you can see in much more detail and see the function of data.
This c4 model stands out to me because it helps to bridge the gap between those involved in the field and those who are not. It provides a concise and organized way of communicating project ideas and patterns to your team and to whom you are working with that may not understand the other diagrams programmers use. For example, UML diagrams are great for programmers but you don’t want to present that to someone who isn’t a programmer. They will have no clue what they are seeing, but with a c4 model you can capture the big picture and have the details on hand as well.
This past week in my Software Testing course I learned about edge Testing. I think when I was first learning about this subject I was more apt to lean towards boundary testing because my thought process was that everything that is supposed to work in a program should work and that’s what is important to test. Anything outside of that can just be blocked and is time consuming and tedious to check because those values will fail. However, I was intrigued by edge testing because it made importance in all values across the domain as well as out of bounds. I saw that it wasn’t enough to just assume the failures, you had to also know why they are causing a failure in order to combat them. Some problems are not easy to find but it is just as important to test the failures as it is to test the correct values and functions. Edge testing is a much more thorough and logical approach. This article was a nice pep-talk and helped persuade my thinking, check it out!
Refactoring is an inevitable location that all programmers reach eventually. Working on any project there is bound to be changes and new ideas or concepts on how to structure the code. With constant updates and inventions coming about everyday for the software world it simply is something we will all have to deal with. We create a program and find that we need to pass different parameter types to achieve a different outcome well now we have thirty plus methods to go back and change one by one. Now while that may be a necessary actions there is another concept to consider, that is adaptation! A good analogy of the Adapter Design Pattern is to consider a program is a cable you use to plug in an electronic device. Imagine that you travel to another country with your device and cable and now you run into the issue of a different wall socket. Your plug won’t fit even though it works just fine back home. Do you go out and buy a whole new wire to make it work with the new power source. No! Simply buy a wall adapter and your cable will work just fine(Of course you should check the voltage in real life, but the idea is the same). Perhaps there is nothing wrong with the structure of you code, you just need it to execute with different data types. By writing an adaptation class you could save a lot of frustration and time refactoring your original code. The adapter and adaptee could function by both implementing an interface and therefore the adaptee would only need to have an “implements … ” statement. In doing this you now have the ability to create any number of adapter methods instead of changing your original code.
A nice simplistic example I found from an online article is that of the Rectangle class. Suppose you write a display() method to display the parameters of the rectangle to the user and the method expects the parameters x, y, w, h. However, the user wants to pass x1, y1, x2, y2 but this will cause an error in the display() method. If an interface is created that hold the display() method then if can be adapted in many ways and fix this issue.
My question to you is; do you think that adaptation is in fact refactoring. According to google the meaning of refactoring is “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”. Think about this, although I’m sure there is a clearcut textbook answer.
SOLID is an acronym for a set of important design principles. Paired together they create a framework for worry free code, and by “worry free” I am speaking of code that would trouble you if any changes needed to be made. In the world today things are constantly changing and being updated and so should your code. If that’s the case then any code you write should have the ability to be edited without causing a complete overhaul of your whole program. Basically what you want to avoid is trickle down effects, and unlike trickle down economics, this is real. If you change one thing or responsibility of a class or variable and that causes a cascade of continuous changes and troubles, then you are experiencing this trickle down effect. To help with this issue is the first design principle in the acronym, Single Responsibility Principle.
Single Responsibility Principle is exactly what it sounds like. Give your classes and methods a sole responsibility so that if they are changed it will only effect that method or classes responsibility. If a class or method handles multiple responsibilities then changing the design of one part may be cause to change the entire entity.
A crude example would be a Rectangle Class. Let us say you have a constructor to build a rectangle object and all it does is take arguments for height and width. However, you also add if and else statements in the constructor to see if the dimensions make a square and printing a confirmation message if it is. Perhaps you even write “if (myShape.isSquare())..” to send the object to a method to, but this is giving the constructor more than one responsibility. If you decide to change the placement of the square check then there will either be duplicated code or you will have to edit the constructor to pass the isSquare result to other methods. Doing any of this would result is test case changes if you were testing the code. In this scenario it is best to have the constructor just be the constructor and to dedicate the square check to its own method like isSquare. In this case if changes were made then only a single class would require changes and not several that are connected in a convoluted fashion.
I think the Single Responsibility Principle is a must know. I remember beginning coding is CS140 and Data Structures and I would try to get as much done in as few methods as possible by cramming in multiple functions into them. I thought the less methods the better but I was so wrong, it’s worth so much more to have many separate methods and classes that each have a sole function. This way code is organized, easy to arrange, and simple to implement or change.
Blackbox testing is a strategy programmers use to test code at the level of the user. They have no access to the source code and only see what a user would see. The goal is to see that everything functions correctly from the view of the user. This type of testing doesn’t require much knowledge of the structure of the program and could be executed without any access to that information.
Blackbox testing can be problematic because you can’t see what part of the code is problematic when running into an error. However, if you have code that is functioning properly, perhaps blackbox testing can be quite beneficial. In a scenario where you have complicated code keep in mind the YAGNI rule (You ain’t gonna need it). Perhaps all bugs aren’t worth testing for, if the user couldn’t trigger the bug then why go through the testing trouble. Yes it is always better to safeguard code against any error but if fixing this hidden bug would over complicate things then just let it be. Blackbox testing comes into play here, if you are not running into errors as the user then consider whether or not you need to safeguard any code level concerns. An article from qablog.practitest.com states, “When we test, the idea is not to find all the issues, we only need to focus on those issues that will affect our users.
The question of “If a tree falls on an empty forest, does it make a sound?” is simple in the context of testing… If there is a bug that no one will run into, then we do not care about this bug!”. Spending time and resources on patching spots of code that aren’t going to be disrupted by a user is a quality issue. Check out this article for more information on this idea.
This web article focuses on UML diagrams and the many reasons why they are so handy in the world of programming. First off, the article explains at a base level of understanding about what UML diagrams are used for. They are sketches, blueprints, and a way of documenting your code before and after it is written. I chose this article because it explains the practical use of UML diagrams and includes many examples. There is so much organized information in the article that it cuts down the google searches and wild goose chase if you have any questions. Check out this organized guide to UML diagrams before you search all over.
This blog will follow a few of my current course including software quality, assurance, and testing. Through using this blog I will track my knowledge and understanding of course material in the final year of my current computer science major. I’ll be posting updates on what I’ve learned, and helpful information on the subject matter , as well as any problems/questions I may have.
This blog will be used as an overview and discussion log for Computer Science material and learning. This blog will be used as a map to track my progress and to share any issues or helpful information.