Tests every developer should run

As mentioned in a previous article on how to fit QA into a DevOps setup, devs and QAs should ideally collaborate to achieve maximum efficiency and optimal product quality. A DevOps pipeline is not complete without a serious contribution from both parties.

When it comes to the developer side of the DevOps table, they should also be able to run rudimentary unit tests on their own code before pushing it to version control. To be able to run these tests, they might need to input from QAs who can guide them on what to check for. This reduces the emergence of bugs in later phases.

This article will discuss a few tests that developers should run on their own code before pushing it to the Quality Assurance phase. Running these tests is an integral part of shift-left testing – the practice of running more tests during the software development phase to minimize defects.

4 Types of Tests that every Developer should run

• Unit Testing: Unit Tests verify the performance of a single method, function or class. They are run on the smallest testable unit of software – procedures, interfaces, classes, etc. They determine if individual units of source code are suitable for integration in the larger codebase.In a unit test, the code being tested should return the right value when fed a set of inputs. Failure to do so marks the test as a failure and the code unfit for further use. The test also provides written assurance that a certain piece of code if perfectly functional, which is useful for other developers who must work with that code.Generally, unit tests are conducted before integration tests. Once a unit test succeeds, the code is integrated into the relevant repository.
• Basic Functionality Testing: Unit Tests determine if the code is returning the right output. But outside of that, devs can use a basic functionality test to evaluate if all aspects of the code works. For example, are all the buttons working? Can a user enter simple text without crashing the whole thing? Can the text on buttons/links be seen clearly?If the code unit is for a feature that must be accessed via an API, functional tests must verify basic API operations. In case the functional test detects an issue that the dev cannot solve, they can push it to the QA with relevant details, which saves time on the testers’ end. Since QAs are trained to solve issues, they will probably have better luck with resolving the issue.
• Code Review: Code Review, sometimes also called Code Peer Review is a practice by which a developer pair with one of their fellow devs to check each other’s code for errors. This streamlines and accelerates the coding process by giving every set of code a second set of eyes for verification. It is common for devs to miss the errors in their own code; an impartial third party is likely to be more thorough and perceptive.Remember that despite all the tools and frameworks in existence, the software is created by human beings who are prone to error. An easy to deal with this very human inclination is to simply another human to help out. A quick, second layer of manual verification can go a long way in cleaning up source code.
• Static Code Analysis: Among the many dev tests out there, static code analysis is the practice of checking the code without executing it. It runs through the basic code structure and ensures that the code is aligned with a numbers of standards and guidelines. Generally, the static analysis looks for the following issues:
  1. Programming errors
  2. Violations of commonly followed coding standards
  3. Syntax anomalies
  4. Security issues
  5. Vague or undefined values

Static code analysis is best done via automation; otherwise it is impossible tedious. The software should scan all untested code in a project before it moves to QA. A static code analyzer checks code against a set of predefined standards and rules to determine if the code complies with them.

If the analyzer does flag any issues, a human developer/tester will have to examine them to verify that they are not false positives. Then, devs can fix apparent mistakes and send the code to testers.

The Role of Real Devices in Developer Tests

All developer testing, regardless of the software being created and tested, must be conducted on real devices. Developer testing can only be effective when tests are being run in real user conditions. Running tests on emulators or simulators cannot provide 100% accurate results, and therefore developers won’t be able to evaluate the quality of their code adequately. Any results yielding from developer tests on emulators or simulators would be only partially correct, and thus development activities based on these results will not ensure high-quality software.

Whether manual testing or automated Selenium testing, real devices are non-negotiable in the testing equation. In the absence of an in-house device lab (that is regularly updated with new devices and maintains each of them at highest levels of functionality), opt for cloud-based testing infrastructure. BrowserStack provides 2000+ real browsers and devices that can be accessed for testing from anywhere in the world at any time.

Users can sign up, select a device-browser-OS combination, and start testing for free. They can simulate user conditions such as low network and battery, changes in location (both local and global changes), and viewport sizes as well as screen resolutions.

Try Testing on Real Devices for Free

By running tests on a real device cloud, developers can run tests with the assurance that they are getting accurate results every time. Comprehensive and error-free testing at the dev-level prevents bugs from showing up (usually magnified) at later stages, which reduces the time and effort required to handle them. It is almost always easier to fix the bugs that devs discover before pushing code. It also allows the software to hit the market faster and reduces the possibility of lost revenue and credibility due to entirely avoidable bugs.