Deploy Without Fear
Using Automated Tests

Chris Stone
https://chrisstone.dev

My goals today

Share lessons learned adding automated testing
Teach some basics of types of tests
Show my appreciation of automated tests and what they can do for us
Inspire people here to write some great tests

Why don't people write tests?

Not sure what to test
Not sure what a "good test" looks like
Someone else is in charge of the tests
Content to test manually

Why do I write tests?

I get scared 😭
I see code I don't understand
I'm worried the deployment had problems
I'm sure I'll forget to test something manually

I don't know what any of this is and I'm scared

I can think of several reasons why I enjoy writing tests. First and foremost...

I can get really scared. Anxious, nervous, worried, all of it.
Maybe I'm asked to maintain code I have never seen before and is really high risk.
I also have tech trauma. I have had so many times when I merged in code that I was so sure was completely fine, only to accidentally cause a major issue, and now, I look at that "squash and merge" button and start panicking.
And maybe there are a set of steps that I am advised to always test when a new release is made, but I can be forgetful. Maybe I take on a code review, and I say, "looks good to me!" and it causes a problem I should have caught because I only tested 19 out of 20 possible scenarios.

Dealing with fear

I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.

Dune by Frank Herbert — *Dune* by Frank Herbert

Dealing with fear

Write tests until fear is transformed into boredom.

Test-Driven Development by Example by Kent Beck — Test-Driven Development
By Example
by Kent Beck

Dealing with fear

Write tests until fear is transformed into boredom.

If something in our application scares me,
that's where I write a test.

If I don't worry about something not working,
then I don't worry about testing any further.

Why do I write tests?

I get scared
Code coverage
Regression detection
Avoid writing superfluous code
Executable documentation

Why do I write tests?

Code coverage

100% is not realistic and not useful.
You can increase coverage while not testing things of value.

Why do I write tests?

Regression detection

Tests should run on every commit in CI/CD
A good test is possible to fail someday
Address flaky tests, team should have faith in the test suite
- Fix if you can
- Skip until you get the time, if necessary

Another reason is regression detection. A good test is one that could conceivably fail. Imagine writing a test that tests that adding two numbers together returns the sum. Addition will always be the same. A good test will test something valuable and meaningful, something that would scare us if it did go wrong.

By putting these tests in our CI/CD pipelines, we get near instant feedback if we have a problem so we can know the exact commit in which the problem originated.
Also, once you do get tests in a CI/CD pipeline, if tests fail, take those failures seriously. If you throw your hands up and say, "it's ok, some of these just fail all the time," the team will lose faith in the test suite, which will lead to people no longer wanting to spend time maintaining them ("they always fail, why bother trying to fix them") and also cause alert fatigue ("the build always fails, it's not worth checking if a serious problem is happening, it's probably just flakiness").
If a test fails for a bad reason, try to get the time to fix it to restore intended functionality if you can.
And worst case scenario, just skip the test until you can get that time.

Why do I write tests?

Avoid writing superfluous code

Test-driven development (TDD)
Red-green-refactor cycle will help drive simple design to avoid accidental complexity
- Remember, refactoring preserves behavior!

Another reason I enjoy tests is because I want to accomplish what I need while writing the least amount of code as possible. I don't want to be clever, I just want to get the job done in a readable and maintainable way. Test-driven development can be a tough thing to wrap one's head around if they have not used it before, and it's not a subject to which I want to devote much time today, but the basics is that you write a test first of the behavior that you want to see given a certain action. That test will not pass at first; in other words...

Red. Then, you write only enough code that makes the test pass, which gets you to...
Green. That's it. Pencils down. If you made the test pass, you did enough. You would then add to that test to make it fail again or maybe write a new test that would fail, but not before you consider time to
Refactor. As long as it was green before and stays green, you can spend this time to simplify the design of the code you have written as long as all tests stay green.
As a reminder, the definition of refactoring is to improve the design of existing code without changing the behavior! If you change how the app works while you are refactoring, you are no longer refactoring, you are instead changing how the app works. That's just a quick conceptual overview of TDD, but I hope it makes sense how writing tests may actually lead to code that does just what is necessary without doing too much.

Why do I write tests?

Tests are the best documentation

Confluence screenshot — Extensive documentation outside the code

Another reason I write test is because I want very good documentation of my code. I think it is great to document decisions around our code and help others explain why things are the way they are. But I'm going to explain why I personally think executable documentation is the best documentation. First of all, consider a huge Confluence document. Having documentation that is far removed from the code means it is less likely for people to encounter it in their standard work. Platforms like this can be very helpful for planning meetings and for documenting decisions and moment-in-time reflections. But if the purpose is to say, "this is how this part of the system works," I guarantee, there will come a day when that Confluence page is no longer telling the truth, and someone is going to waste their time trying to reconcile a misconception.

Why do I write tests?

Tests are the best documentation


export function isLevelInDanger(oldScores: number[],
		newScore: number) {
	// An alert should be displayed
	// if the new score is less than average.
	const sum = oldScores.reduce((a, b) => a + b);
	return newScore < (sum / oldScores.length);
}

Comments can lie

Why do I write tests?

Tests are the best documentation


export function isLevelInDanger(oldScores: number[],
		newScore: number) {
	// An alert should be displayed
	// if the new score is less than average.
	const sum = oldScores.reduce((a, b) => a + b);
	return newScore <= (sum / oldScores.length);
}

Comments can lie

Why do I write tests?

Tests are the best documentation


export function isLevelInDanger(oldScores: number[],
		newScore: number) {
	const sum = oldScores.reduce((a, b) => a + b);
	return newScore <= (sum / oldScores.length);
}


it("should only alert when less than average", () => {
	const actual = isLevelInDanger([1, 2, 3], 2);
	assert.deepStrictEqual(actual, false); // FAIL
});

A test will fail if it becomes untrue.

Why do I write tests?

Tests are the best documentation

What does it mean for writing to be effective?

Readable
Relevant
Applicable

And just like any document we would write for any purpose, we have several considerations we need to make. The act of writing is usually intended for some audience to read, whether it is ourselves or others.

For one, the things we write should be readable. Just like with any code that we write, we optimize for readability. We know that code that just works but is difficult for a human to interpret is bad quality and that we can do better.
The things we write should also be relevant. Going back to the fear thought, we should only be testing things that are worth the execution time when running and are worth the human time of reading. Imagine if we had a bunch of UI tests that do nothing more than mount a component, assuming success because nothing was actually asserted. We would be better off removing those entirely so that someone trying to find meaningful tests finds something meaningful.
Our writing should also be applicable. If we have code that is too difficult to refactor, but we were able to get a test around it, then others who will need to test in this area will find that very useful. On the other hand, a test that we write for ourselves that is not likely to ever fail and is not likely to instill fear in others should make us think twice about keeping it. It is totally acceptable to delete tests from our suite that no longer serve us.

Types of tests

Unit
- Tests a small unit of isolated simple design code
- Mocks out any calls to an external dependency, data layer, or API interface
- Runs in milliseconds
Integration
- A relatively small area of code that is allowed to talk to other components or a test database interface
- Runs up to a few seconds
End-to-end
- Tests a full user behavior journey using browser protocols or emulated devices
- Runs up to tens of seconds

There are dozens of kinds of tests, and many people will give you all kinds of definitions. All I can tell you today is that these are the definitions I have used. Some may disagree, but this is how I categorize most kinds of tests, whether they are back-end, front-end, or even infrastructure-focused.

A unit test is one that tests a tiny amount of isolated simple design code, mocking out any call to an external dependency, data layer, or API interface. As a result, they should run very fast, in terms of milliseconds.
Integration tests will also test a relatively small area of code, but it is allowed to talk to other components or a test database interface. As a result, it may take up to a few seconds to run.
End-to-end tests cover a full user behavior journey using browser protocols or emulated devices. These tests will take the longest, taking tens of seconds on average to run.

Types of tests

Which type to pick

Pick the lowest level that gives value.

That alone sort of simplifies the whole concept, and it's possible to consider some gray area middle ground. And you could even technically pick any one of these tools and be better off in situations than you'd be without any of them. But why you'd go for one over another depends on various considerations.

Mike Cohn's Testing Pyramid is referenced by many people to illustrate how, starting from unit tests and going up to UI or end-to-end tests, the execution gets slower as more integration is required. The idea is that the level of investment at each level should go down the further you go up, focusing on unit tests.
Kent C. Dodds' Testing Trophy is another perspective, though. Some projects may not have much complicated business logic that is worth testing in isolation, but the integration between components could be a vital layer. I think both of these approaches give us interesting things to consider. Ultimately, what I tell people is to not worry too much about whether you're investing too much in one area or not, and instead,
confirm that, when you go to write a test, you are picking the lowest possible level that gives you value for the behavior that you need to test, the behavior that would give you fear until you tested it.

Which type to pick


export function isLevelInDanger(oldScores: number[],
		newScore: number) {
	const sum = oldScores.reduce((a, b) => a + b);
	return newScore <= (sum / oldScores.length);
}

	Unit	Integration	End-to-end
Effort	✅	✅	❌
Value	✅	✅	✅

Let's start with this example again. I know this is overly simplistic, but imagine a function kind of like this that we did want to test. Let's say we were doing some super complicated mapping and reducing here.

It wouldn't take much for us to write a unit test around this. We could even very easily have parameterized test cases to test several conditions.
An integration test wouldn't take too long either, let's say the calling function wanted to fetch those scores from the database, so we could seed it and then set our expectation based on what we expect it to get.
An end-to-end test is possible, but the level of effort required to put it together will be a very hard sell, and parameterizing it significantly may be a no-go.
That said, if we did put it together, and worked hard at it, we could prove that it works.
But we could do that with unit and integration too. So our choice is between a test that will take milliseconds to run in memory or a few seconds to stand up a test database, seed it, and then close the connection.
In this case, we get the value we really need from the unit test.

Which type to pick


var dbStaticResources []db.StaticResource
query := s.dbClient.
    Model(db.StaticResource{}).
    WithContext(ctx).
    Distinct().
    Select(
       "static_resources.id",
       "static_resources.grade",
       "static_resources.title",
    )

if input != nil {
    if input.ResourceType.IsValid() {
       query = query.Where("static_resource_type = ?", input.ResourceType)
    }
    if len(input.Grades) > 0 {
       query = query.Where("grade IN (?)", input.Grades)
    }
    if len(input.SubjectAreas) > 0 {
       query = query.Joins(`INNER JOIN subject_area_resource_mappings ON
             subject_area_resource_mappings.static_resource_id=static_resources.id             AND subject_area_resource_mappings.deleted_at IS NULL`).
          Where("subject_area_resource_mappings.subject_area_id IN (?)", input.SubjectAreas)
    }
    if len(input.TaskTypes) > 0 {
       query = query.Joins(`INNER JOIN task_type_resource_mappings ON
             task_type_resource_mappings.static_resource_id=static_resources.id             AND task_type_resource_mappings.deleted_at IS NULL`).
          Where("task_type_resource_mappings.task_type_id IN (?)", input.TaskTypes)
    }
    if len(input.Keywords) > 0 {
       query = query.Joins(`LEFT JOIN keywords_resource_mappings ON
             keywords_resource_mappings.static_resource_id=static_resources.id             AND keywords_resource_mappings.deleted_at IS NULL`).
          Joins(`LEFT JOIN keywords ON keywords.id=keywords_resource_mappings.keyword_id
             AND keywords.deleted_at IS NULL`)

       innerQuery := s.dbClient.WithContext(ctx)
       for index := range input.Keywords {
          innerQuery = innerQuery.Or("keywords.keyword ~* ? OR static_resources.title ~* ?",
             fmt.Sprintf(`.*%s.*`, input.Keywords[index]),
             fmt.Sprintf(`.*%s.*`, input.Keywords[index]))
       }
       query = query.Where(innerQuery)
    }
}

err := query.Joins("File", func(db *gorm.DB) *gorm.DB {
    return db.Select("id", "url", "thumbnail_url")
}).Find(&dbStaticResources, "static_resources.is_archived = false").Error
if err != nil && !errors.Is(err, gorm.ErrRecordNotFound) {
    return nil, fmt.Errorf("services.GetAll: Error running query find: %w", err)
}

	Unit	Integration	End-to-end
Effort	✅	✅	❌
Value	❌	✅	✅

How about this example? We have some complicated logic here but all it does is determine what SQL we end up using to hit the database. First of all, what kind of tests are feasible for code like this? All of them, I can write any of these types to see that this works. We do have a lot of conditions that we may want to check all at once though. If we really want to test various conditions here, and if we think about the setup required...

It won't be tough to set up some mocks for a unit test or seed some data for an integration test...
But if we wanted to do something more end-to-end, then we could be looking at duplicating this test and all of its setup multiple times.
But that's not to say we can't get the value for which we're looking if we go down that path.
But we can get that value from integration tests that actually hit the database too.
But I'm actually not sure that we get much value from a unit test here. If we set up a mock for our database, even if we verify the actual SQL, we get to return whatever data we say that database should return, and we have no idea if the SQL is correct.
So for this example, an integration test feels like the right level.

Which type to pick


// test that a user can record audio and submit a message

	Unit	Integration	End-to-end
Effort	❌	✅	✅
Value	❌	❌	✅

Now let's suppose that we have a need to test that a user can record audio and submit a message. We could write various integration tests but how can we prove that one leads to another and everything feeds into one another?

I can think of this in terms of the human behavior of what they want to perform and what they hope to see, but it would require so many interconnected units, there is basically no way to unit test this. We could unit test various points along the way but that doesn't address the goal for this test we want to write.
We could maybe put something together with several key integration tests that hit APIs that we know it will require.
And we could also write a full end-to-end test of the entire process that a user experiences.
Which honestly is fitting our need. If we had concerns about just the upload feature or just the displaying of recordings feature, we could do those in integration tests...
But for this, we decide that the value we hope to achieve is that the user not only will eventually see this info but that they instantly see it as soon as they navigate to that page. To truly test that full user experience, which we do feel is a critical need for our application,
we decide that, despite the longer runtime and trickier maintainability of end-to-end tests, that that is the right level for this.

How to get started

You have to start somewhere

Test the change you want to see in the world

Be the change you want to see in the world

Adding back-end tests

The more we prepare data in the backend for how the frontend will use it, the more we can rely on quick back-end unit tests.
Difference between a unit and integration test may just be whether an interface is mocked or if its implementation is actually used.

One nice thing about this project is that there were back-end tests, just not a lot of them. But at least it gave us a starting point.

Something to consider in general with back-end development is that, if you know how the front-end will interact with this data, and you can do all of your in-memory modifications in the back-end, then you can unit test those modifications in what will generally be your fastest tests to run of all.
There are several libraries out there for all kinds of languages, and the tool is not going to be what determines if it is unit or integration, it is whether dependencies behind interfaces are mocked or if we actually allow the code to hit a test database or a test API.
Our back-end is Go, and the project used Testify, which we continue to use; it is a great library. On .NET projects, I have used NUnit and xUnit. There are many options for your needs.

Adding back-end tests


func TestMyFunction(t *testing.T) {
	var myTests = []struct {
		inputValue     int
		expectedOutput string
	}{
		{inputValue: 2, expectedOutput: "critical"},
		{inputValue: 3, expectedOutput: "low"},
		{inputValue: 10, expectedOutput: "high"},
	}
	for _, tt := range myTests {
		actualOutput, actualError := MyFunction(tt.inputValue)
		require.Equal(t, tt.expectedOutput, actualOutput)
	}
}

Adding end-to-end tests

Highest and smallest on both the pyramid and the trophy
That doesn't mean to not write them; they can be very helpful

On my team, we inherited an application that had been developed by a third party, and testing was not in a great state. There were a few unit tests, no integration tests, and the only end-to-end tests that existed hadn't been run in a year, so many just failed now.

End-to-end tests are on the top of the pyramid, and it is generally agreed that they take the longest to run, and it can hurt to see them fail.
But that does not mean to avoid them. They are a powerful tool, and end-to-end test libraries have only improved with time. Many teams have success with libraries like Selenium and Cypress...
But we chose Playwright as our tool of choice. It runs very fast, it comes with support for different browsers out of the box, and there is a very strong community behind it.

Adding end-to-end tests


test('teacher can create new assignment',
		async ({ page }) => {
	await this.page.goto('/login');
	await this.page
      .locator('.MuiCircularProgress-svg')
      .waitFor({ state: 'hidden' });
	await this.page.getByRole('combobox').fill(districts.newDistrict.districtName);
	await this.page
		.getByRole('option', { name: district, exact: true })
		.click();
	await this.page.getByRole('textbox', { name: 'Username' }).fill(users.teacher.email);
	await this.page.getByRole('textbox', { name: 'Password' }).fill(process.env.USER_PASSWORD!);
	await this.page.getByRole('button', { name: 'Login' }).click();
	await expect(this.page.getByLabel('account of current user')).toContainText(
		`${users.superAdmin.firstName} ${users.superAdmin.lastName}`,
	);
	await this.page.getByRole('button', { name: 'create Assignment' }).click();
	await this.page
		.getByRole('main')
		.getByRole('button', { name: '', exact: true })
		.click();
	await this.page.getByText(className).click();
	// ...
});

We started with Playwright Codegen

Starting is actually very easy. Once you have set up a Playwright project, while there is certainly a learning curve to understand how to best use it, it is possible to dive right into creating tests using their test code generation tool. It will open up a browser and record all actions you take and generate a test for you.

As you can see, it even tries to use semantic information from your page to determine reliable locators.
But you can still get weird results if your app is not accessible. In this case, I am trying to click on what I think is a drop-down select element, but it is actually constructed of other components, where the drop-down arrow is a button that has no text, so we look for a button with absolutely no text. Just looking at this should be a red flag because, if our test can't target anything more specific about this button and its perceived role, then what hope does someone using a screen reader have? But this is the best it can do for now, so we make note of that for our accessibility audit we aim to have.
But at least we have a test now. But it's not very readable, is it? It could be much, much worse, but if someone wanted to know, what is the purpose of this test, it might take a while to truly understand.

Adding end-to-end tests


test('teacher can create new assignment',
		async ({ loginPage, header, teacherPage }) => {
	await loginPage.login(
		districts.newDistrict.districtName,
		users.teacher.email,
		process.env.USER_PASSWORD!,
	);
	await expect(header.usernameButton).toContainText(
		`${users.teacher.firstName} ${users.teacher.lastName}`,
	);
	await teacherPage.createNewAssignment();
	await teacherPage.chooseClass(classes.newClass.className);
	// ...
});

We refactored with Page Object Model

So we then took some time and refactored our test code to using the Page Object Model pattern. We are performing the exact same operations here as before, but everything related to logging in can be abstracted into a function, and the idea of clicking a button called Create to create an assignment could benefit from some readability. It's in a better direction now. Page Object Model always feels a little bit controversial to me though, because if we just abstract every single line, then we are hiding the true functionality, and it's easy now to change what these functions do without remembering to change their names. But I still ultimately enjoy this pattern because it does increase readability, and we can understand the intent of a test much easier.

One of our next big changes to the app was around the login process. We got about a dozen tests up and running, and every single one of them needed to go to a brand-new session and login as a user all over again. It can be very time intensive, not to mention it looks like suspicious behavior.

Adding end-to-end tests


test.use({ storageState: StorageStates.teacher });
test('teacher can create new assignment',
		async ({ teacherPage }) => {
	await teacherPage.page.goto('/');
	await teacherPage.createNewAssignment();
	await teacherPage.chooseClass(classes.newClass.className);
	// ...
});

Took advantage of Storage State

Adding front-end tests

Many libraries exist that help with both unit tests and integration tests.
Some front-end testing may be considered "component testing".

➡️

Now that we covered the critical paths with end-to-end testing, our attention turned to the fact that we had no testing in our front-end.

There are many libraries for front-end testing in web development, and many of them can be used for both unit and integration testing.
There is also a lot of support for component testing. As for what component testing is, it depends on who you ask. In my experience, if you were to ask me, I still think of my tests as being unit or integration based on whether I am testing a very small amount of isolated behavior or if I am testing the integration between different parts of my code or the integration of my code with a database or API layer.
We use Vite as the build engine for our React app. There are several libraries we could have chosen...
But ultimately picked Vitest. It works much like Jest but has a similar build configuration to Vite, so they play nicely together, and it seemed like a good choice for a new library for this project.

Adding front-end tests


const keywords: MockedResponse<GetKeywordsQuery> = {
	request: {
		query: GetKeywordsDocument,
	},
	result: {
		data: {
			keyword: [{ id: '1234', keyword: 'hello' }],
		},
	},
};
it('should add new keyword', async () => {
	const onChange = vi.fn();
	render(
		<MockedProvider mocks={[keywords]}>
			<AddKeywordTags onChange={onChange} />
		</MockedProvider>
	);

	const combobox = screen.getByRole('combobox');
	await waitFor(() => expect(combobox).not.toBeDisabled(), {
		timeout: 500,
	});
	await userEvent.type(combobox, 'world');
	expect(screen.getByDisplayValue('world')).toBeInTheDocument();
	await userEvent.keyboard('{enter}');
	expect(onChange).not.toHaveBeenCalled();
	expect(screen.getByText('Add a new keyword')).toBeVisible();
});

On my current team, we inherited a project that had all kinds of front-end components but not a single front-end test. It was something that always bothered us, and it did not make sense for us to go in and start adding hundreds of tests when we could be working on feature work. But when we started tackling something that behaved a bit strange in the front-end, it was our opportunity.

Notice that we are trying to keep this behavior-focused. We want to think of this less as what data outputs do we want for given data inputs, but rather what result should a user see when they interact in certain ways.
Sometimes, though, it can be hard to truly get out of implementation details. This here is not ideal; we are mocking a function and asking about whether it got called. The reason for this is that the way this component had been written, this would be incorporated on a form, and it would manage all change events and form states. We could do this another way if we wanted to test the entire form on which this component is used, but that is more than we wanted to test for this story.

Adding to CI/CD


jobs:
  build:
    name: Lint and Test TypeScript
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - name: Setup Node.js environment
        uses: actions/setup-node@v3
        with:
          node-version: '22'

      - name: Checkout repository under $GITHUB_WORKSPACE
        uses: actions/checkout@v3

      - name: Install dependencies
        run: |
          cd packages/apps/web
          yarn install

      - name: Lint for web-app
        run: |
          cd packages/apps/web
          yarn lint

      - name: Build for web-app
        run: |
          cd packages/apps/web
          yarn build

      - name: Test for web-app
        run: |
          cd packages/apps/web
          yarn test

Pull request required checks

Tests that require manual runs are easy to get ignored and your team can miss out on valuable feedback, so once you start getting some tests together, even if it's just your very first one, you want to start getting this in an automated run.

In our case, we actually already had a CI pipeline that made sure that every pull request to main went through a build process to verify that the app was in a good state.
So with that, we were able to add our testing to this step now.
We also, for the first time, added lint checks. When we first ran a linter in our project, we received many errors and it kind of seemed overwhelming to start taking action on them, so we downgraded known project errors to warnings so that new errors will fail this action first before we even get to the build, and if both the lint and build succeeds, the test is the last line of defense before we allow a PR to be merged.

Adding to CI/CD


jobs:
  e2e:
    name: Run the e2e tests
    uses: ./.github/workflows/_shared_run_e2e_tests.yml
    with:
      ENVIRONMENT: prod
    needs: [deploy-api, deploy-web-app]
    secrets:
      E2E_USER_PASSWORD: ${{ secrets.E2E_USER_PASSWORD }}
      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

End-to-end tests after every deployment

Thank you!

Chris Stone
https://chrisstone.dev

Deploy Without FearUsing Automated Tests

My goals today

Why don't people write tests?

Why do I write tests?

Dealing with fear

Dealing with fear

Dealing with fear

Why do I write tests?

Why do I write tests?

Code coverage

Why do I write tests?

Regression detection

Why do I write tests?

Avoid writing superfluous code

Why do I write tests?

Tests are the best documentation

Why do I write tests?

Tests are the best documentation

Why do I write tests?

Tests are the best documentation

Why do I write tests?

Tests are the best documentation

Why do I write tests?

Tests are the best documentation

What does it mean for writing to be effective?

Types of tests

Types of tests

Which type to pick

Which type to pick

Which type to pick

Which type to pick

How to get started

You have to start somewhere

Adding back-end tests

Adding back-end tests

Adding end-to-end tests

Adding end-to-end tests

Adding end-to-end tests

Adding end-to-end tests

Adding front-end tests

Adding front-end tests

Adding to CI/CD

Adding to CI/CD

Thank you!

Deploy Without Fear
Using Automated Tests