A common challenge in event-driven architectures is the potential for unintentionally triggering downstream consumers when running end-to-end tests.
Ephemeral environments can help, but not when you must publish events to a shared event bus.
In such cases, you can conditionally create a local copy of the event bus as part of the ephemeral environment so your test events will not trigger downstream event consumers.
There is more than one way to test user journeys that span multiple bounded contexts. Your choice depends on organizational structure, team responsibilities, and the maturity of your testing practices.
Ultimately, every part of the user journey should be tested, whether it’s done piecemeal by individual teams or centrally by a QA/cross-functional team.
In this article, let’s look at several ways you can approach this problem, depending on if you have full-stack teams or specialised frontend and backend teams. We will look at trade-offs and whether it’s best to host other teams’ services in your environment, or use mock APIs, or delegate testing user journeys to a QA team and use a dedicated integration environment for testing.
Testing is an integral part of software development, and serverless is no different.
Test Driven Development, or TDD, is long regarded as a leading practice in software development. And yet, one of the most misunderstood parts of Test-Driven Development (TDD) is the “Driven” part of the name. It’s not just about “writing tests before you write the code”. If your tests do not inform and drive your API design, then you’re not really doing TDD.
In this post, let’s look at how we can apply the TDD mindset to serverless and use our tests to drive the design of our serverless application.
When I previously wrote about testing Step Functions, I gave you a general strategy that consists of: Component tests that target the Lambda functions (specifically, the custom code you wrote in those functions). End-to-end tests that execute the state machine in the cloud. Local tests using Step Functions Local where you can use mocks to …
Testing Step Functions: how to skip time when testing Timeout and Wait states Read More »
Several people have asked me about unit testing CDK applications recently. The questions often go something like this: “Because it can be in Python or TS, people bring up unit testing for CDK, whereas it’s not even thought about with Serverless Framework, SAM or Terraform. What are your thoughts on this?” “I have so many …
No, you don’t need to test every line of your CDK application Read More »
Testing Step Functions can be a daunting task. However, with a little preparation and effort, the testing process can be simplified and streamlined. In this article, we will provide a practical strategy on how to test Step Functions. So let’s start by setting the stage and introducing the players. What makes Step Functions hard to test? …
Update 17/09/2019: based on feedback, I added a few more alternatives that do not require you to deploy additional Lambda functions to the e2e-test stage. Scroll to the end to find out more. Being event-driven is a key characteristic of a serverless architecture. Often our Lambda functions would publish events to SNS topics or Kinesis …
How to include SNS and Kinesis in your e2e tests Read More »
Oh, the Pain! For a long time, unit testing non-public methods in C# has been a pain in the back side. In order to test a non-public method (most likely private methods) you have a number of choices each with an undesired effect: The easiest way out is to make the methods public. However, this …
.Net Tips – using InternalsVisibleTo attribute to help testing non-public methods Read More »
Some time ago I read about (might be on DotNetRocks) a little gem coming out of Microsoft’s research lab called Pex, which is a framework for doing automated White Box Testing in .Net. It’s still in its early days (despite having been around for more than 2 years now) but packs a bag of potential …
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.