marxxxx/gist:93bf4a0a75ec906752ff9b9496d7c1bc

## gistfile1.txt
The anatomy of the refactoring-resistent tests i was refering to above is basically this:

Arrange
- Setup dependencies by mostly using actual prod code, including actual instance of db, mocks/stubs only for external services i don't control
- Get system to a state required to execute the behavior i want to test by using public api of the system (e.g. when i register a user i need for the test, i execute the same code that would be executed when a user would register by using the actual software, i don't fake the state with stubs or take shortcuts by adding prepared data to db directly) i want the software to get to the desired state by running the actual production code

Act
- Execute operation i want to test

Assert
- Verify executed behavior. If i don't get a direct result back by executing the operation i inspect the state of the system by using public api of system (e.g. to verify if a user was registered successfully i don't inspect the users-db-table directly but call a "GetUserDetails"-Operation which is already in use in the actual system to get user information).

Setup of those tests can become very tedious. I usually use Helper-Setup-Methods (e.g. SetupRegisteredUser) to mitigate this issue.
Those kind of tests are also slow to execute.

But they allow me to completely refactor the code behind the public api surface i am testing and i still get feedback if the desired behavior is working. I just have to probaly wire up some services in a different way in my Setup-Method and i'm good.
They also give me confidence that the code that is running in prod will be working as i'm running a lot of prod code and test the integration between different parts of the system, not just isolated functionality.
	The anatomy of the refactoring-resistent tests i was refering to above is basically this:

	Arrange
	- Setup dependencies by mostly using actual prod code, including actual instance of db, mocks/stubs only for external services i don't control
	- Get system to a state required to execute the behavior i want to test by using public api of the system (e.g. when i register a user i need for the test, i execute the same code that would be executed when a user would register by using the actual software, i don't fake the state with stubs or take shortcuts by adding prepared data to db directly) i want the software to get to the desired state by running the actual production code

	Act
	- Execute operation i want to test

	Assert
	- Verify executed behavior. If i don't get a direct result back by executing the operation i inspect the state of the system by using public api of system (e.g. to verify if a user was registered successfully i don't inspect the users-db-table directly but call a "GetUserDetails"-Operation which is already in use in the actual system to get user information).

	Setup of those tests can become very tedious. I usually use Helper-Setup-Methods (e.g. SetupRegisteredUser) to mitigate this issue.
	Those kind of tests are also slow to execute.

	But they allow me to completely refactor the code behind the public api surface i am testing and i still get feedback if the desired behavior is working. I just have to probaly wire up some services in a different way in my Setup-Method and i'm good.
	They also give me confidence that the code that is running in prod will be working as i'm running a lot of prod code and test the integration between different parts of the system, not just isolated functionality.