Alex-Yates/tSQLt_explained.txt

## tSQLt_explained.txt
Title:
tSQLt explained, by the maintainer

Abstract:
Back when you released quarterly, you might have got away with week-long manual testing cycles. However, DevOps has highlighted the risk associated with long lead times and large, complex deployments. Most of us understand the need to move much faster.

Unfortunately, continuous delivery, without continuous testing, is simply a more efficient way to deliver new bugs to production. It's all very well being able to deploy 10 times a day, but if you can't test 10 times a day, you are entering a Russian Roulette tournament without an exit strategy. It's no surprise that "DevOps Transformations" that skip the testing tend to fail.

We'll start with a bit of theory. What types of tests should you be writing? How many tests should you be writing? When should you be running the tests? How should you approach legacy databases? How is the role of the tester evolving?

Then we'll get practical. tSQLt is the de facto unit testing framework for SQL Server. We'll assume zero prior knowledge by demonstrating how to install the framework and to write and run your first unit test.

We'll go on to discuss some of the common challenges (managing test data, testing constraints, mocking dependencies etc) before finishing with a look at some of the common patterns and practices recommended by the tSQLt maintainers.

If you are a SQL Server developer or DBA who cares about delivering working software, and you seek guidance about effective testing, this session is for you.
	Title:
	tSQLt explained, by the maintainer

	Abstract:
	Back when you released quarterly, you might have got away with week-long manual testing cycles. However, DevOps has highlighted the risk associated with long lead times and large, complex deployments. Most of us understand the need to move much faster.

	Unfortunately, continuous delivery, without continuous testing, is simply a more efficient way to deliver new bugs to production. It's all very well being able to deploy 10 times a day, but if you can't test 10 times a day, you are entering a Russian Roulette tournament without an exit strategy. It's no surprise that "DevOps Transformations" that skip the testing tend to fail.

	We'll start with a bit of theory. What types of tests should you be writing? How many tests should you be writing? When should you be running the tests? How should you approach legacy databases? How is the role of the tester evolving?

	Then we'll get practical. tSQLt is the de facto unit testing framework for SQL Server. We'll assume zero prior knowledge by demonstrating how to install the framework and to write and run your first unit test.

	We'll go on to discuss some of the common challenges (managing test data, testing constraints, mocking dependencies etc) before finishing with a look at some of the common patterns and practices recommended by the tSQLt maintainers.

	If you are a SQL Server developer or DBA who cares about delivering working software, and you seek guidance about effective testing, this session is for you.