Test Doubles — Fakes, Mocks and Stubs.

Hello everyone and today’s topic for my final blog post for 443 is going to be about test double in software testing. In this article they discuss three implementation variations of testing doubles which are fake, stub and mock and gives examples when to implement them. I know from class that they are missing at least one more test double which is dummies so I’m thinking these three fake, stub, and mock are mainly used. First, fake is defined as the same as the activity we work on in class which is “fake are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code”. A good analogy of a short cut is a repository. Fake implementation will not be involved database but will store data using a collection which allows us to not start up the database and save more time from request when involving with integration testing. Fake implementation is also great for prototyping and spikes. Second is stub and this defined the same as the activity we work on in class too which is “stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects”. An example would be instead of grabbing from the database where design a stub like a method and controlling it’s return value. Stubs is a good option for testing query type methods which are “methods that return some result and do not change the state of the system” because you can confirm the return value of the method. Finally, mocks are “objects that register calls they receive. In test assertion we can verify on mocks that all expected actions were performed”. A good example of mock that they give is when you want to test a system like a security system that check if the window and door is closing in order for the security system to work, you don’t actually want to call the real door and window instead you can create mock window and door to test the interactions to see the functionality of the security system because the closing is a responsibility of the door and widow and that should be tested separately in unit testing. All in all, these are the test doubles they discuss in this article stub, mock, and fake and they are all make software testing much simpler.



Differences between the different levels of tests

In these 443 blogs post I am going to write about the differences between the different levels of tests. There are four basic levels of tests which are unit/component testing, integration testing, system testing, and acceptance testing. Unit testing when you separate each part of the program and test them individually and confirm that they perform what they were design to do. This is usually done in the beginning of the development and usually done by the developer first than hand over to the testing team. Integration testing is when you break the program into combinations and test if they actually work together. This exposes any flaws that show if the components don’t work together or not. There are many ways this can be tested, bottom up or top bottom. System testing is one of the higher levels of testing. It’s when you test the whole program to ensure that it all work properly and meets the requirements. This is one of the most important steps before deploying the product and it confirm that the product is almost ready to ship. This can be tested in an area where user can test the product. This usually done when a special testing team to see if the product fulfills its requirements for the business. Acceptance testing is involving a lot of user end. Acceptance testing test whether the system complies with the user end. This step is to find out many different problems that can occur like bugs that can harm the product in anyway. During this step you can find out if the program will be installed or not into the user’s system. Every single of these testing levels is important and testing early to avoid error in the future and testing for often is well worth it. This important because finding and fixing errors near the finishing stage which be more difficult and more time consuming than finding them early. All in all, these four levels of tests are important, and I learned more about those four after reading this article. It changes the way I work because I know the importance of the levels and what to do in those levels.


Why you need to know these 9 automated testing tools for Java

Hi everyone and welcome to my sixth 443 cs blog post. Today I’m going to go over this article that I am certainly reading which is titled “why you need to know these 9 automated testing tools for java”. This article explains how do selenium, junit, grinder and other automated testing tools work and how to use them. Testing java applications is important because you must ensure that your program is supposed to do what it is doing. There are many automated testing tools for java, but this article goes over the most common and useful of them. First, there are different types of tools for different kinds of situations. For example, unit testing is for newly written code before its incorporated into the base of the code. Next, integration testing prevents the application from crashing from newly written code. Also, to test the performance of the application you would use performance and user experience testing. Finally, to test the vulnerabilities of the application to would use security testing. These are some the testing methods and there’s many more and some of these methods are used for multiple purposed. This article listed what the best automated testing tools for java and there are:

  1. Junit which is the most popular and is usually for unit testing
  2. Testingng which is a versatile tool because it can be used for unit test, integration test and many others.
  3. Jtest which is good for security testing.
  4. The grinder is for performance testing.
  5. Gatling which is also a performance testing.
  6. Selenium which is for interface and experience testing.
  7. Mockito which is good because it makes it fast and easy to write automated java test.
  8. Powermock which is a unit testing framework.
  9. Arquillian which allows you to write tests that execute in real runtime environments.


All in all, this article is very helpful and change the way I think about this subject because I did not know there was so many testing tools out there and the purpose of each testing tools. I now know what and when to use the automated tools depending on the situation.

Equivalence partitioning and boundary value analysis

Hello everyone, and welcome back to my 443 blogs where I post many interesting topics that I am currently learning. Today blog post topic is about boundary value analysis and equivalence partitioning. Boundary value analysis is a testing technique where you test between valid and invalid inputs. Boundary values are also known as lower/upper values and errors are often observed in those ends. It’s considered a black box testing technique. Equivalence partitioning and boundary value analysis can co-exist and used together to test many more areas of the test. Boundary value analysis test is proficient because it can test most of the test product. Equivalence partitioning is when we categorize the values into ranges and test one input from each of category. This is also a black box test design technique and can be applied to several different test like unit, integration, etc. Equivalence partitioning would have numerous amounts of test cases that we cannot test all. All in all, this blog post is about Boundary value analysis and equivalence partitioning. The resources that I gather my information was from https://reqtest.com/testing-blog/what-is-boundary-value-analysis-and-equivalence-partitioning/. I thought this blog was good but didn’t provide much information about this topic other than basic. The examples that this blog provide wasn’t descriptive enough for me to truly grasp on the idea of equivalence partitioning and boundary value analysis. After reading this blog, it didn’t change the way I think about the subject because I already knew most of the content, but I was looking for more details. I thought the blog should of include more visual examples with actual test inputs. I learn some useful tips on this subject like for example that we can’t test all possible cases in equivalence partitioning because the test cases would be too large. Also, even though this resource was simple it’s was easy to understand the material and the example wasn’t complex, so it was easy to follow. I agree with everything in the article and like the way it explains the topic. In conclusion, this was my 443-blog post and I learned many interesting things from this recourse that I used.

Decision Table Testing

Today blog is about Decision Table Testing. “Decision table testing is a testing technique used to test system behavior for different input combinations” and known as cause and effect table. The table consist of rules, cases, and test conditions. This tutorial has a good and easy to understand example. It created a decision table for a login screen where the output is true if both conditions, username and password are true else the output would be false. There were four rules because there were two variables. There was also another example that was similar which had eight cases because there were three variables. The test would only pass if and only if three of the conditions were true else it would return an error message. This test method is important because it allows us to test several combinations of tests which allows us to have more coverage of on the tests. There are many advantages of decision table testing:

  1. “When system behavior is different for different input and not the same for a range of inputs”
  2. It provides better coverage for testing because it has many combinations.
  3. Any complex conditions can be converted into a decision table.
  4. Great for low input combinations, will cover all testes.

But there is one big problem with decision table testing and that is when there are many inputs the table gets complex and complicate things. This article was very helpful to me. Because I have a better understanding of decision table testing now. This tutorial had many good examples and even a video on decision table testing. The formula for possible combinations is 2 ^ n, where n is the number of inputs which is shown in this article which I remember during class. I think after reading this article I change the way I think about decision table testing because I now know what it’s best used for. I found this article very interesting because of the clever examples that it uses its. All in all, the decision table testing is one of many important testing methods out there.



This blog post is about second of level of software testing. Integration testing is when individual units are merged and tested as a group. The purpose of integration testing is discovering errors in the interaction between integrated cases. A good example of integration testing is a basketball hoop, the rim, the pole, and the net. They are created and tested separately in the same facility but when two unit or more are ready they are tested together which is integration testing. Black box testing, white box testing and gray box testing can all apply to this method. There are many approaches to integration testing:


  1. Big Bang – when every or most of the units are merged together and tested at the same time.
  2. Top Down – when lower level units are tested after top level units.
  3. Bottom up – when top level units are tested after lower level.
  4. Sandwich/Hybrid – combination of both top down and bottom down testing method.


Integration testing is important level of software testing because for example if you have a two separately created and tested units like a door and door knob, even though both door and door knob were tested you don’t know if they would fit because they weren’t tested together. There could be many faults for example like the door was inch in width smaller or the door knob was didn’t fit with the door. With integration testing the door and door knob would be tested together after each of the unit is ready so if there any error that makes the door and the door knob to be non-compatible then the test cases will fail which shows that there’s an error and you can fix it.


After reading this article I have a better understanding of integration testing. This article changes the way I think about software testing because I more knowledge about one of the levels of software testing. I now know why integration testing is so important. I find this method useful in many ways in testing in general outside of software testing. All in all, integration testing is important level of software testing.


Black Box Testing vs White Box Testing

Today blog is about Black Box Testing vs White Box Testing. First, Black Box Testing is when we’re testing if a system is functional or non-functional without knowing the internal structure (code). There’re many techniques that can be used for designing black box tests like Equivalence Partitioning, Boundary Value Analysis, and Cause-Effect Graphing. All these techniques are similar as they all are testing input values with valid output values. There are also many advantages with Black Box Testing. First, the tester doesn’t really have to be a programmer or need to know how the program is implemented. Second, the test is using done more hands-on and with user’s point of view which allows reviews of the product to be more unique in a way that every tester/user have a different opinion on the product. There are also disadvantages for Black Box testing. First, there are not a lot of many inputs that can be tested which means there is still many of the area of the product that are left untested. Second, without the specifications the test cases are difficult to design. Also, testes can be redundant because of the lack of test. An example I think is good for Black Box testing like tester testing an app by using it and checking if every action works as it should.

White Box testing is when you have full access to the information of the product and test the internal design. It tests the input of the test’s cases with the expected output.  A great example of White Box Testing is “like the work of a mechanic who examines the engine to see why the car is not moving”. White Box testing is usually applied to unit testing, but I think it’s the most effective method because you have all the specifications and most all part of the product will be cover. The disadvantages are that it requires skilled developers because some tests are complex.

All in all, both Black Box testing and White Box testing are both effective in their own way. Black Box testing is mainly for Acceptance testing and White Box testing is for unit testing. I like White box testing more because I full access to the code which means I can better understand the mechanics of the system.