Logistics
- Secret code is:
- Masks may be off if you are tripple vaxed and healthy
- How did it go with Authentication?
Background
- Service testing is key when building a Service Oriented Architecure
- It is exactly analogous to End-to-end testing or integration testing
- It supplements basics of Unit Testing
- It’s an extension of testing in general
- Concurrent software is the most difficult kind to reason about
External APIs
- External APIS - Web APIs provided to you by another company altogether
- You don’t control it. The response time may vary dramatically from test to test
- You might need tokens or log ins. There may be quotas (maximum number of calls)
- The service may not be free
- You need to make sure that your code behaves correctly no matter what that service does
- You cannot fix bugs in the service, all you can do is respond in a safe way
- However: We are focused here on *internal” service APIs
- Since you control that the considerations are different
How Services are put together
- By definition what makes it a service is that is accessed over HTTP
- The functionality is invoked via a URL (or queue – for later)
- And it produces results by returning JSON (or XML – for later)
- We happen to be using Sinatra for dispatching HTTP routes and returning JSON
- Usually it’s a good idea to provide a ruby library to invoke the service
- Keep the app server aspect (e.g.
sinatra
) as thin as possible
- Create your functionality from POROs (Poro Service Objects)
Unit Testing Services directly
- It’s no different from any other automated test
- Either it invokes the actual URL:
require "faraday"
require "json"
url = "http://dummy.restapiexample.com/api/v1/employees"
data = Faraday.get(url).body
result = JSON.parse(data, symbolize_names: true)
assert_equal :success, result[:status]
- Or it uses your own provided API library
require_relative xxx
result = get_employees
assert_equal :success, result[:status]
Additional material
Thank you. Questions?
(random Image from picsum.photos)