Presentation given during the IT Probe 2009 Event of the Junior Philippine Computer Society of Adamson University in Manila -- October 17, 2009. I gave a brief introduction of Test Driven Development and presented a very simple sample program that shows how TDD is done.
Presentation given during the IT Probe 2009 Event of the Junior Philippine Computer Society of Adamson University in Manila -- October 17, 2009. I gave a brief introduction of Test Driven Development and presented a very simple sample program that shows how TDD is done.
Copyright:
Attribution Non-Commercial (BY-NC)
Formatos disponibles
Descargue como PPTX, PDF, TXT o lea en línea desde Scribd
Presentation given during the IT Probe 2009 Event of the Junior Philippine Computer Society of Adamson University in Manila -- October 17, 2009. I gave a brief introduction of Test Driven Development and presented a very simple sample program that shows how TDD is done.
Copyright:
Attribution Non-Commercial (BY-NC)
Formatos disponibles
Descargue como PPTX, PDF, TXT o lea en línea desde Scribd
Jacinto Limjap, Jr. Microsoft Most Valuable Professional – Visual C# Senior Software Design Engineer, Cormant Technologies Agenda • What is TDD? • What is TDD not? • Arrange, Act, Assert • TDD Mindset • How to test in isolation? • What about the database? • Integration tests suck because... • What is TDD? • Using unit tests to design software • Allows change in code without fear of (inadvertently ) changing functionality • Produces loosely coupled objects and methods with single responsibilities What is TDD? • Unit tests are just side effects: main point is DESIGN • Write tests first, code later (?!) What is TDD not? • Substitute for QA testing • Necessarily means successful project • Silver bullet Writing tests • Think about how you want to express your code and intentions • Think about inputs, and intended output • Separate small, isolated areas of functionality • Arrange, Act, Assert • Arrange all necessary preconditions and inputs • Act on the object or method under test • Assert that the expected results have occurred • Mindset Red • New code – Write test before implementing class/method – Internal workings of classes/methods should not matter • Existing code – Write test to reproduce bug Green • Write least possible code to pass all tests • Take shortcuts if necessary Refactor! • Applies to both implementation code and unit test code • Change code without changing functionality (ergo, without introducing bugs) • Remove implementation shortcuts – make sure software design is sound/follows tenets of OOP • Optimize for design/performance/maintainability • Rinse and Repeat! How to test in isolation? • Classes and methods should have single responsibility(!!!) • Loose coupling • How to test in isolation? • Stubs – Method returns a specified result, e.g., property getter returns a constant value • Mocks – Asserting that a certain method has been called within a test – Test checks for the method call, not the result, but some tests check for both What about the DB? • Integration tests – Makes sure everything works together – Also applies to the file system, web services, etc... – Handles everything that can fail without your absolute control Integration testing sucks because... • Fragile Tests – Depends on state of external system – Breakage cause lost confidence on tests – even if it's not the tests' fault • Usually leaves artifacts behind (files, orphaned DB data) Question and Answer