Category Archives: Unit Testing

Week 9 Blog Post

Choosing a topic for this week I tried to find something we had recently touched upon. Last week we went over mocking and expanding my knowledge of this topic can benefit me and the class. Searching for articles about mocking I stumbled upon one that shares the negatives of using mocking data. To counter-attack the ideas we learned in class it is always great to know both sides to using a concept. 

This article doesn’t fully dispose of mocking but gives ideas when it’s good to use. It gives a variety of examples including “Isolating the unit under test from other components or dependencies that are not relevant to the test, Speeding up the test execution by avoiding network calls or database queries that can be slow or unreliable, and Controlling the test input and output by creating predictable and consistent data that can be easily verified”. These ideas are then counterposed to the negatives such as “Introducing errors or inconsistencies between the mock data and the real data, which can lead to false positives or false negatives in the test results, Reducing the coverage and confidence of the test, by not testing the actual behavior and logic of the external source or the interaction with it, and Increasing the maintenance and complexity of the test, by requiring extra code and logic to create and manage the mock data”. The flaws of mocking data are mainly it does not use real data making it much more different from the real data creating disparities between the two. These tests ignore scenarios with much more complexity and these error and bugs can go unseen. The author assures the reader to use a data source to improve the tests.

After reading this article it gave me insight into the negatives of using mocking. The week prior activities made the use of mocking reduce time in creating classes but it’s good to know when it should be used and when it shouldn’t. I wish there was a perfect solution for every test but to find bugs in your code you must expand your horizon. Reading this article made me see that a variety of tests testing different things can overall benefit you. You never have to completely ignore a type of test but being able to see the positives and negatives can save you in the long run. Plus it will allow you to have a broader knowledge knowing that this may have flaws but there are things I can add to have a satisfactory end product.       

https://medium.com/@queenskisivuli/why-mocking-data-is-a-bad-practice-for-testing-a20d2d7104aa

From the blog CS@Worcester – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Unit Testing vs. Integration Testing

The basic idea of unit testing is that you are testing individual units of source code that you have written to see if there are any bugs. Usually the code is deterministic so there are set outputs. The idea of integration testing is to test how a group of modules in your application are working together including how external dependencies are working with the code. This usually involves testing something that is non-deterministic in the application.

Integration testing usually comes after unit testing and is the more expensive to maintain. While the developers will run the unit tests, integration tests are usually required to be ran by a test team. This is partly due to the difficulty in finding errors in integration tests as well as the time it takes.

Integration testing is black box testing which means you are testing the inputs and outputs of the interface. An example of an integration test would be checking the interface to see if you are brought to your profile home page when you enter your username and password. Unit testing is white box testing so you are writing test cases for certain functions to see if they perform correctly. An example of a unit test would be writing a JUnit test case to test the deposit() method and assert that when you make a deposit of $50 to your bank account object (with initial balance of $0) that your balance is now at $50.

The main takeaway is that integration testing tests the interface and how multiple modules work together while unit testing is testing the source code of one function. Unit tests are done in early development while integration tests are done after you have some sort of product complete.

Sources:

https://www.guru99.com/integration-testing.html#3

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.