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.