Test doubles are a method of unit testing that allows a user to test how the code interacts with an external dependency. It is intended to focus on the code being tested rather than the behavior of the external dependencies. As such, a preset object is used to represent those dependencies and their intended behavior. This allows a section of code to be tested even when its external dependencies are not yet finished or are not yet working. There are several types of objects used as test doubles: dummies, fakes, stubs, and mocks.

Dummies are objects that are passed but never used. In most instances, they are only used to fill out a parameter and are used as a placeholder for arguments.

Fakes are objects that simulate the external dependency by implementing the same interface without interacting with any other objects. Fakes are typically hard-coded in order to represent the correct behavior and must be modified whenever the interface is modified. A new fake object must be created for every unique test case.

Stubs are objects which return a result based on specific input, and they do not usually react beyond the scope of the test. Stubs will usually have all the methods required by the external dependency but will provide hard-coded returns that may need to be altered depending on the test case.

Mocks, much like stubs, will return a result based on a specific input. Mocks can also be programmed with data like the number of times its methods should be called and in what order.

Sources:
https://devopedia.org/mock-testing
https://www.telerik.com/products/mocking/unit-testing.aspx

From the blog CS@Worcester – Ciampa's Computer Science Blog by graceciampa and used with permission of the author. All other rights reserved by the author.

This week I wanted to learn a little more about code reviews. As first I thought, “Yeah code reviews just get someone to look at your code isn’t that common sense?”. After looking into it more I learned code reviews have a lot of benefits that you might not think of.

Code reviews share knowledge. Most people are going to be working as part of a team. With code reviews there is always more than one person that understands some portion of the project. This makes the team more flexible. With this shared knowledge also comes a better ability to estimate how much work some portion of the project is. When the reviewer gives feedback the are also exposed to the complexity that may underlie an issue. This gives multiple informed inputs to create more reliable estimates for the team.

Code reviews also give you a break from the monotony of a certain task. If you are spending a lot of time on a certain part of the project, doing a code review is like a breath of fresh air. It is liberating to work on a different area of the project. It can even feel fun, almost like a vacation.

Code reviews can also motivate developers to work harder. When you know one of your peers is going to take a look at your work you might take an extra effort to create something you find presentable. You would want your code to be clean and for all your tests to pass.

Code reviews are really more than just having someone else look at what you have done. They are an important part of any software development team and deserve to be formally incorporated into the development process.

atlassian.com/agile/software-development/code-reviews

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

An important part of software testing is the testing of the software itself. But what if you were able to automate the testing? One of every programmers core ideals is to try to automate as much as possible, because programmers are “lazy”. One framework that allows you to do this is Gradle. Gradle is a build automation tool rooted on JVM, so it is perfect to use with Java. We can use GitLab’s Continuous Integration tool to allow our code to run and test every time it is pushed to GitLab. This is very useful so that any changes made are automatically test each and every time an update is pushed to Main. Once you have your Java project set up, you need to initialize Gradle into the directory of the Java project. After you have done that, you can copy your Java files to the Main src folder in the new Gradle section in the directory. All of your test files will go to the Test src folder. You can then run gradle build to build the project, then gradle test to run all of your tests in the test files using the files in the Main folder.

After this and gradle test outputs successfully, you can set up GitLab’s Integration by using the .gitlab-ci.yml file in your project. After you have added that, all you need to do is use Git to commit and push your project to GitLab and then check the CI/CD tab to watch your tests run.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

When testing software, it can be useful to have testing objects in place to help test methods and functions to ensure correct output, but without having a real object. This is where the multiple types of test doubles come into play. There are four types of doubles, dummies, fakes, stubs, and mocks. Dummies are objects that are passed around, however never actually used. They are commonly used to fill parameter lists and the like. A fake is an object that actually works, unlike a dummy, however there is usually some kind shortcut taken that does not make them suitable for final production. A stub is used to get a certain answer from a test, and they will not respond to any outside input, only what they are programmed to do. And lastly, we have mocks, which are objects pre-programmed to respond to certain expectations given the input of the calls they receive.

These objects are all very useful when it comes to testing, as they can all help save time when only certain aspects of a program need to be tested, without having to use the full functionality of a particular object. Dummies are nice in that they can help with filling lists and arrays. Fakes are also nice because they allow you to have a part of an object without having to use the full object itself if you want to test only a part of an object. Lastly with mocks, we can use them to get predetermined outputs for certain inputs, which would assist with testing.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

I the world today, everyone is looking for fast solutions and fast technology. The world is expanding rapidly, especially in technology, so many things are being automated to increase how fast things get done. There comes test automation that falls into these categories to make testing faster, and not rely on manual testing which would take much more time. A lot of the manual testing methods people may use such as regression or unit testing manually, is a time waster and is not efficient for people to do constantly when it can be automated. For test automation, the tests are run automatically and the goal of it is to improve the quality of the software in the most efficient way possible. There is a general criteria that needs to be followed in order for a test case to be suitable for automation. These requirements include that the tests are repeatable and there are many factors for this steps. In order for tests to be repeatable, they need to first set up the test by including the data and environment. Then they need to execute the function and the part of the software that is being tested. And lastly once everything is run, the data needs to be cleaned and the environment it was created in. The next criteria is that it needs to be determinant, which means that the output of the test is the same each time with the same input. The last criteria is that it needs to be unopinionated, meaning human judgment and error in that tense cannot be a factor when the tests are run. Now all the different types of automated tests include code analysis, unit testing, integration testing, automated acceptance testing, regression testing, performance test, etc. Overall, automation has made testing a lot more efficient and the process a lot more easier in a way since it saves much more time than having manual tests in many circumstances.

Links:

https://www.testim.io/blog/what-is-test-automation/

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Unit testing is a form of software testing where part of the software is tested and working. Recently I’ve been introduced to some methods of unit testing where a temporary object is created in place of an existing object in order to perform testing. The term for this is “Test Doubles”, as just like an actor in a movie has a double, doubles are created for objects in the program for the purpose of testing them. I’ve learned about different types of test doubles in my Software Quality and Test Assurance course, and I’d like to examine a few and give a brief explanation about how they work. The names of these test doubles are dummies, stubs, fakes, and mocks.

Dummy objects are made for the purpose of allowing methods to call an argument, and therefore they do not have any implementation themselves. These are used for methods are not actually important for your tests. For example, if you are trying to test a method and have it return something specific, then a dummy method can be created instead of making a method with code that isn’t relevant for the test.

Stubs, similar to dummy objects, are created for the use of testing code without needing to fully develop it. A test class is called to the stub, and the stub returns a value that is controlled. This is useful for scenarios where the result of the test changes depending on what the input is.

These test doubles make testing for code easier. They reduce the need of excessive code and allow for the methods in the test class to simply call the these test doubles instead. Each different test double has its own use depending on the objective you are trying to reach with your testing.

This article and blog provided very useful info regarding what each test double does and demonstrated each type of test double with examples.
https://dzone.com/articles/test-doubles-mockito
https://mokacoding.com/blog/swift-test-doubles/#:~:text=Dummy,the%20behaviour%20you%20are%20testing.

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

After working with Checkstyle in the recent activity, I wanted to look more into other static testing tools, but this led to me focusing on the purpose and function of static testing. I had an idea on how it worked prior to the activity, got practice using one of its tools in the activity, but I wanted to read more about static testing in general to get a better grasp on the concept and how it works.

Static testing is based around testing code without actually running the code, as opposed to dynamic testing that checks the code when it runs. The two main static testing techniques are manual examination and automated analysis using tools. Static testing is effective because it can catch early mistakes, takes less time to test, and leads to improved productivity. Checkstyle was the main tool that we worked with, but there are others such as Soot and SourceMeter.

I think the main aspect of static testing that I wanted to learn more about was how it compared to the normal testing that we have been working with, and after working with stubs and mocking in the past activities, it feels similar to mock testing because it seems more about testing behavior than state. It felt like that way to me because JUnit tests can still run when the static test picks up errors if the errors are programmed to be ignored, similar to how a JUnit test may pass but not work properly because it picked up a different method that had the same return type, which is the purpose of behavior testing.

However, with static testing, the proper method can be called and the code could have the right behavior and state, but still not pass because of errors found with the test, such as Checkstyle, which finds errors due to the selected coding style/standard. These errors can also be coded to ignore and still run.

https://www.guru99.com/testing-review.html

https://www.guru99.com/static-dynamic-testing.html

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

For my final blog post for the class, I decided to look at a blog post from Codacy. In this blog post, they talk about how only about 15% of developers use static analysis tools and that more people should. The blog post starts by talking about in the past a lot of developers manually look for errors and bugs within their program and how this method of code analysis is very error-prone because humans are prone to making errors and are likely to miss a bug or two. I hate to admit it but I agree with them on this point. Human beings are flawed and will inevitably make a couple of mistakes. We don’t know when or how but we will. This is just a part of human nature. Computers can run many more tests than we can and very quickly find errors and save a lot of time and money in development. Even though static analysis tools are powerful, we still need to pair with some dynamic testing because static analysis cannot account for every thing that could happen or go wrong.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.