#testing
15 posts

The best ways to test your serverless applications

For the serverless functions you write, test for each of the following risks: configuration (databases, tables, access rights), technical workflow (parsing and using incoming requests, handling of successful responses and errors), business logic and integration.
Read more

The best ways to test your serverless applications

  • For the serverless functions you write, test for each of the following risks: configuration (databases, tables, access rights), technical workflow (parsing and using incoming requests, handling of successful responses and errors), business logic and integration (reading incoming request structures, storage order in databases).
  • Break up functions into hexagonal architecture (ports and adapters) with separation of concerns through layers of responsibility.
  • For unit tests, use a local adapter or mock as an adapter to test the function business layer in isolation.
  • Use adapters to simulate to test integration with third-party end services. Save memory and time by testing not for full integration but file storage integration with the in-memory adapter.
  • For proper monitoring of integrations, use back-end tools such as IOpipe, Thundra, Dashbird, Epsagon, etc., and front-end tools such as Sentry or Rollbar. You can also use an open-source error tracking app such as Desole that you install in your AWS account.

Full post here, 10 mins read

5 advanced testing techniques in Go

Use test suites - develop tests written against an interface for all implementations of that interface. Carefully consider interfaces before exporting them and avoid creating a hard dependency between a consumer package and your own.
Read more

5 advanced testing techniques in Go

  • Use test suites - develop tests written against an interface for all implementations of that interface.
  • Carefully consider interfaces before exporting them and avoid creating a hard dependency between a consumer package and your own. To avoid exporting an interface, use an internal/package subtree to keep the interface scoped to the package.
  • Don’t export concurrency primitives, especially channels and the sync package. Also, add documentation on whether a struct or package is safe for concurrent access by multiple goroutines.
  • Use net/http/httptest to speed up tests and run them in parallel more easily, without binding to a port or setting up a server.
  • Use a separate _test package inside the foo/ directory of the package you want to test, rather than the default package pkg. This is a workaround for cyclic dependencies, prevents brittle tests and lets you see what it is like to consume your own package.

Full post here, 8 mins read

Four load testing mistakes developers love to make

Being too focused on what you set out to test and ignoring any other warning signs while testing is a common mistake developers make. Reusing test data is another common mistake.
Read more

Four load testing mistakes developers love to make

  • If you run a short load test and it works fine, it is no guarantee that your service can handle that load for a long time. You should run your performance tests for more time and understand your system’s performance characteristics.
  • Being too focused on what you set out to test and ignoring any other warning signs while testing is a common mistake developers make. It’s good to pay attention and investigate unusual results or changes in your application’s behaviour as you increase load.
  • Reusing test data is another common mistake. You should either generate new data or spin up a new environment for each test.
  • Assuming the production environment is perfectly healthy permanently. Deliberately make things to go wrong during your load test to find out how your service will perform if such failures happen.

Full post here, 7 mins read

Four steps to creating effective game day tests

List all potential failure scenarios. Create a series of experiments to anticipate how things will break. Test your human systems. Address the gaps and patch any holes you find.
Read more

Four steps to creating effective game day tests

Game Day tests deliberately trigger failure modes in production systems to practice response to unpredictable situations.

  • List all potential failure scenarios. Consider which parts of your infrastructure are completely safe, what are your blind spots, what happens if a server runs out of space or in case of a DNS outage or DDOS attack.
  • Create a series of experiments to anticipate how things will break - what side effects may be triggered, whether alerts will be correctly dispatched, whether downstream systems may be affected.
  • Test your human systems. Consider how team members need to interact when an incident unfolds.
  • Address the gaps and patch any holes you find. Check which hypotheses held up in practice and which ones did not. Establish a plan to correct these and run a new Game Day test to check whether your hypotheses are now valid.

Full post here, 6 mins read

The big bad guide on database testing

Check for data mapping, ACID properties and data integrity of your DB, and ensure they implement your business logic accurately.
Read more

The big bad guide on database testing

  • Check for data mapping, ACID properties and data integrity of your DB, and ensure they implement your business logic accurately.
  • The most common test techniques are transactions for the ACID properties, checks of keys and indices, parameters and results of stored procedures, evaluation of triggers and field constraints, etc.
  • Stress testing and performance testing are critical too.
  • SQL queries are the most reliable way to qualitatively test apps with low or medium complexity.
  • Use a database testing tool that considers the business, data access and UI as well as the database itself.

Full post here, 8 mins read