The AAA (Arrange-Act-Assert) pattern advocates that you divide your test method into three sections: arrange, act and assert. This pattern is also known as the Given-When-Then pattern, a concept within [[BDD]]. 1. **Arrange**. Firstly, you need to set up our pre-conditions for the function under test. Here you can initialise any objects, or data you need for your test. You can also define the output value you expect from your code after execution 2. **Act**. Next, you call your code with the specified inputs for your test. Call your function or method with the given input as though you were calling the code in production. 3. **Assert**. Lastly, you will verify your expectations based upon either the output value, or the code paths executed. You know what you expect your code to do so you can now check that it happened. If it didn't, then the test has failed and your code, or sometimes your test, is incorrect.[^ml1] [^ml1]: [Different types of software tests](https://www.marclittlemore.com/different-types-of-software-tests/) by [[Marc Littlemore]] This pattern works well for authoring different types of automated tests including [[Unit testing]], [[Integration testing]] and [[End to end testing]]. A unit test example is:[^med1] ```csharp // arrange var repository = Substitute.For<IClientRepository>(); var client = new Client(repository); // act client.Save(); // assert mock.Received.SomeMethod(); ``` [^med1]: [Unit Testing and the Arrange, Act and Assert (AAA) Pattern](https://medium.com/@pjbgf/title-testing-code-ocd-and-the-aaa-pattern-df453975ab80) In certain test runner frameworks (e.g. Mocha and Jest for JavaScript), the Arrange code may be added outside of the main test function in a special setup function that the test runner framework automatically invokes before a test is run. ## Open questions - Are there any genres of automated tests for which this assertion doesn't necessarily hold true?