 So the session is about Test Driven Development of Infrastructure Code, and I'm Sridhevi. I work as a lead consultant with ThoughtWorks. I have been in software testing for about 10 years now. I was testing different kinds of applications in a couple of domains, worked on building test frameworks for most part of my career, and I also worked on different languages. So that's about me. This is my Twitter handle and my LinkedIn profile. So why are you here? I would like to understand what your expectations are from the session. What are you expecting to learn here? What is TDD? I'm not sure about the new way, but certainly a way. How the infrastructure code can fail with the test fields? I mean, how it fails with how the test passes, because the cycles are very fast, and infrastructure too, how it creates and fails. So it's a slow process, infrastructure is a slow process. So I think you need to reconcile how it happens. So how testing can happen against infrastructure code, and how fast or how easy it is to test it. Yeah, I think we'll cover that. Okay, anybody? Okay, this is a demonstration. So I'm going to show only Chef. The concepts I'm sure are going to apply for any configuration management framework. But from my experience, Chef has better testing support than Puppet. It actually comes with out of the box testing frameworks, which I'm going to use here. Chef is a configuration management framework. I'll talk about it. I have a small Chef 101 basics kind of a slide. All right. So what is test-driven development? I think most of you might have attended today's keynote, and the speaker actually spoke in depth about test-driven development. So he compared tests as automated warning signals in a nuclear power plant, actually. So when he was talking about that, I thought...