This course continues the subject of Test First Development and adds concepts such as Acceptance Tests, Behavior Driven Testing, Context Specification, and advanced isloation techniques. A variety of tools are used to showcase the various possiblities and styles of testing.
David Starr is Director of Technical Learning at GoDaddy, Inc. He specializes in agile software development practices, patterns and practices, and judicious application of various technologies within development teams. He is a 5 time Microsoft MVP in Visual Studio and a technical instructor with Pluralsight where he focuses on the software development practices and developer tooling curricula. David blogs at ElegantCode.com, is a frequent contributor at conferences and a frequent writer. He has successfully led many product development teams and is a technical learning professional.
Test First Development II Hello, this is David Starr and welcome to the Test First Development II course. If you haven't yet seen the Test First Development I course, I strongly recommend you take a look at it, because it talks about basic techniques of test first development. This course will focus more on the different techniques that we might use within test first development with a special consideration for why test first developers do some of the things that they do. Even if you're writing Unit Tests in your work today, I strongly encourage you to go back and at least watch the last module of the TFD one course on Isolation. We'll be expanding a lot on isolation in this course. This first module, Language and Levels of Developer Testing, focuses on the very real problem of communicating what someone wants the software to do and our ability as software developers to prove that our software meets those requirements. There are many nuances and techniques that we'll see along the way. l This module starts off by trying to reground ourselves in some fundamentals of testing, just to remind ourselves what we're actually trying to accomplish here and why. We'll then move over into talking about talking about software. Those conversations that we have with people who want us to turn their ideas into code, can by really tricky. Luckily, much of the test first conversation can be about making this communication go much more smoothly. And we'll see how to make someone's desirements, that is an idea for what they want the software to do, and then turn that into requirements, which as we'll see are now going to be defined as tests that prove the software actually meets the requirement expressed as tests.
Acceptance Test Driven Development Hello, this is David Starr and in this module we're going to get our hands dirty with Acceptance Test Driven Development or ATDD. This is a fairly new and burgeoning area of interest in. NET development and represents the most promising efforts we're making in our search for Executable Specification. The style of test creation that we'll see in this module is very definitely a test first practice and one that helps developers drive the design and functionality of our applications. And in addition, acceptance tests as we'll be working with them, are meant to be full integration tests that test functionality all the way through the stack in a fully integrated test environment. The most promising quality of the test that we'll see are that they endeavor to actually serve as the specification or the requirement for the software being created. In this module we're going to have a general discussion about acceptance testing, what are automated acceptance tests really are, what they're intended to do, and how we're going to work with them. And then we'll move over to looking at some tools, specifically we're going to take a look at Gerkin, a DSL for helping us express requirements. And then SpecFlow, a tool that works with Gerkin to help us actually write those Executable Specifications. This is really part one of a two part module, if you will, we'll see a few more acceptance test focused tools in the next module. Not really advocating for anyone over the other, SpecFlow just happens to be the one we're starting with.
More Acceptance Test Driven Development Hello, this is David Starr and this module is very much a continuation of the previous module in the Test First Development two course. We're going to explore a few more tools in this course that help us create acceptance test in our pursuit of acceptance test driven development. The first tool we'll look at is StoryQ, which provides a very competitive alternative to what we've seen already in SpecFlow; just a little bit different take on it. And finally, we're going to wrap-up by looking at a technique for accomplishing this style of development simply using a plain old unit testing framework, that is not including more tools other than our unit testing tools, but still be able to provide those Executable Specifications with the appropriate reporting that give us something to talk about with our customer. . . .
Behavior Driven Development Hello, this is David Starr and welcome to this module on Behavior Driven Development in the Test First Development II course. We're going to continue that outside in approach of testing using some techniques prescribed by behavior driven development. In the previous modules of the course we focused on acceptance test driven development. We've seen how incredibly fluent we can make our tests, that is how readable they can be an expressive. We're going to try and continue that trend even as we go beyond the high level functional area and focus on levels of our application below the surface and create tests that will probably only be seen by other developers. I'll tell you that the techniques you'll see in this module are exactly how I write my unit tests in the real world. When I'm working on production software environments, behavior driven development is my test first technique of choice. In this module we'll spend a bit of time understanding where this behavior driven development idea came from and try and get a handle on its essence. I'll show you some techniques that I've used in production software systems for rolling my own test framework that works really well with a behavior driven approach. So far as we develop using these techniques, we've already made use of mocks, even in our integration tests. When we introduce mocks or double type objects into our tests systems, we have a choice of different verification styles. And we'll have a look at what that means in this module, as well as introducing a new tool: Machine Specifications or MSpec.
More Behavior Driven Development Hello, this is David Starr and we're going to continue flushing out a few more ideas and details in this continuation module focusing on behavior driven development. This module will introduce a few situations that you very well may run into when running real production code; like how to reduce coupling and testing an abstract class. We want to write Unit Tests around that abstract class; how do we isolate it? And then after seeing how we solve some riddles like those, we're going to have a look at code coverage. We'll see how code coverage can help us as an effective tool for deciding what tests we need to write, but without using it as a set of handcuffs. . . .