Automated API Testing — A Developer’s perspective

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

Myth around 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

Unit tests, Integration Test, Service Tests, System Tests

  1. Infrastructure dependency

Unit tests (Basic)

Unit Testing using Mocks

  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

  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

  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

  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

Conclusion

--

--

--

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

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Essential Steps of Testing Your App before each Release

HOT’s Tasking Manager 4: How we built it

How to add Klaytn to MetaMask

Build your first full-stack serverless app with Angular and AWS Amplify

GitHub Action — Deploy Applications to AKS

Examining 12 Months of SEPTA API Queries

Getting Json data from yaml file of Kubernetes

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/

More from Medium

Scuba Diving in South Goa for Beginners

Book Review: Cytonic (Skyward #3) by Brandon Sanderson

Final Reflection