100%(1)100% fanden dieses Dokument nützlich (1 Abstimmung)
881 Ansichten17 Seiten
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)
Verfügbare Formate
Als PPTX, PDF, TXT herunterladen oder online auf Scribd lesen
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)
Verfügbare Formate
Als PPTX, PDF, TXT herunterladen oder online auf Scribd lesen
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