Automated API Testing — A Developer’s perspective

Sourced from https://images.app.goo.gl/zagkTdCayUmZU4A27

Myth around tests

Myth 1— The name leads many to believe that Junit tests are always unit tests

  1. Developers have to invest good time just to find out it passes now. Developers now unknowingly are conditioned to start ignoring test results.
  2. When the test fails for real reasons, developers conditioned to ignore, ignore it.
  3. Such flaky tests give a false sense of the system being good.

Automated testing

  1. There is initial investment involved in terms of defining the test.
  2. This is good for regression testing where the same piece of code has be tested again and again in the same manner.
  3. This enables the CI (continuous Integration) practice in the team where the code in develop branch is always production ready. Whether you can embrace CD(continuous deployment) aspect depends on your organization, but aligning to CI is always a possibility.
  4. This reduces the overall cost of testing
  5. Also this increases the confidence in the solution both for the product owner and the developer
  6. As a side effect, this also serves as a well-maintained documentation of the system usages for new developers.

Manual Testing

Manual testing is costly as compared to Automated testing both in terms of the time for execution as well as the cost of resources working/setting it up. But manual testing has it’s own place. Few scenario’s

Unit tests, Integration Test, Service Tests, System Tests

Within testing, the tests are classified in different flavors depending on factors like

  1. Infrastructure dependency

Unit tests (Basic)

They are tests which can work with the run-time engine (ex. JRE). It is self contained and does not make any calls to infrastructure elements like the databases, caches, message-bus etc.,

Unit Testing using Mocks

When tests have to reach out to other modules or other infrastructure elements which sometimes are not available. Mocks are useful in below scenario’s & have their own place

  1. Infrastructure is not yet provisioned
  2. Dependent modules are also under development
  3. Dependent modules have heavy memory needs which you cannot run in local
  4. Existing infrastructure elements the latency is such that the tests cannot finish in finite time.
  5. The test has a dependency on another service the availability of which is beyond your control. To prevent tests from being flaky, you may have to mock the source of your system interfaces.
  1. If mocks are introduced for reasons #1, #2, #3, with efflux of time, the mocks become invalid w.r.t. the real systems, are forgotten to be maintained, giving a false sense of healthy system, overruling the very purpose they are there and issues are finally uncovered directly in production.
  2. Several of the mock frameworks are provided by the mock frameworks not by infrastructure solution teams, therefore there is no guarantee that the API behavior will be identical between the mock objects and real elements. This could lead to incorrect tests.

Integration Tests

Integration tests are test that expect the dependent modules or infrastructure to be in place & will reach out to them during the test run. The test coverage therefore includes

  1. Creating the input to the test and feeding it to the test program.
  2. Testing your actual code
  3. Testing your talks correctly to the infrastructure
  4. Testing that the infrastructure is set up correctly for your test
  5. Testing that the infrastructure is available & responding
  6. **This can span several components and infrastructure elements
  7. Test the output is received by your code
  8. Test that the output matches your expectation.

Service Tests/System Tests

These both terms are used interchangeably depending what bounded context you are referring to. If you are testing the system interfaces, it is called a system test. If you are testing a service interface, it is called a service test. And follow are its characteristics

  1. They are integration tests using infrastructure elements.
  2. They are end to end tests of the service or the system, treating them as black boxes
  3. They have the maximum ROI. With minimum investment in tests you can go from 0 to 50% coverage just by covering the system interfaces.
  4. They are mandatory for any system aiming for 80% coverage.
  5. A lot of time, though Junits are good to start on this, Junit’s alone are not sufficient to test them. You have to either see if there some tool that can be put to use. In most cases, proprietary a hybrid testing framework that uses a a combination of data driven test and other testing flavors are employed.

Test Driven Development

The tests are the 1st thing that are written during a feature development. The characteristics are

  1. TDD is the concrete implementation of the true Agile spirit and the shift left paradigm — Testing is no longer done at the end of development.
  2. This results in reduced cost of development and testing. Early detection of bugs and resolution. Early recognition of concerns and communication.
  3. First write the tests — What you expect out of the system. Define the input and the output from the test
  4. Build the functionality to satisfy the test— How you implement the feature to satisfy the what above.
  5. Tests are written in a all encompassing manner — Pre-requite data is prepared as part of the test. After the test, the data is clean up.
  6. These tests can be used for regression testing
  7. Technologies like Junit and TestNG are widely used in the Java world.

Few frameworks

There are lots of frameworks in the market today. I will touch upon the few most famous ones.

Conclusion

The ultimate objective of the testing is to create a quality product, create a smooth experience for the end-users, great working environment for developers, have a production ready code for product-owners, be production-ready always and thereby become Agile in the true sense. Quality is not built in a day, its a habit, that worth embracing.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sarada Sastri

Sarada Sastri

Java Architect | MongoDB | Oracle DB| Application Performance Tuning | Design Thinking | https://www.linkedin.com/in/saradasastri/