Building a Testable Data Access Layer


Published on

All developers understand the theoretical value of unit testing, but with data driven applications, figuring out how to create tests can be hard. In this session, you will learn how to design and build a data layer that can be tested. We will introduce data layer architecture practices and methodologies that make testing possible, and cover the basics of unit test mocking. You will also be guided through various types of testing, including unit, integration, and functional testing. Leave this session with the basics needed to start creating tests for application data layers, including those powered by LinqToSQL and Entity Framework.

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Visual Studio Live Orlando 2010MGB 2003 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
  • Easy = Easy to build if you’re not careful
  • Everything is familiar up to this point. Now the dreaded step may of us avoid: Creating tests for the data layer
  • Hides issues example = concurrency, auto-gen DB values, etc.
  • Building a Testable Data Access Layer

    1. 1. Building a Testable Data Access Layer Todd Anglin Chief Evangelist, Telerik Level: Intermediate
    2. 2. Introductions <ul><li>Todd Anglin </li></ul><ul><li>Chief Evangelist, Telerik </li></ul><ul><li>Microsoft MVP </li></ul><ul><li>ASP Insider </li></ul><ul><li>President NHDNUG & O’Reilly Author </li></ul>@toddanglin
    3. 3. today’s plan
    4. 4. what is a “data layer”?
    5. 5. Data Layer <ul><li>Responsible for talking to “persistence layer” </li></ul>Presentation Web Desktop Domain Logic (“the code that makes you money”) Data / Model Service Persistence Database Cloud XML Etc.
    6. 6. why build a data layer? what’s the benefit?
    7. 7. importance of data layer <ul><li>Decouple application from persistence </li></ul><ul><ul><li>= easier maintenance </li></ul></ul><ul><ul><li>= improved testability </li></ul></ul><ul><ul><li>= greater reusability </li></ul></ul>
    8. 8. Presentation Web Desktop Domain Logic (“the code that makes you money”) Data Persistence Database Cloud XML Etc. Service
    9. 9. a good data layer…
    10. 10. <ul><li>Handles all data access </li></ul><ul><li>Hides implementation </li></ul><ul><li>Flexible </li></ul><ul><ul><li>Easy to refactor </li></ul></ul>
    11. 11. a bad data layer is…
    12. 12. <ul><li>Does not centralize data access </li></ul><ul><li>Makes application very dependent on persistent store </li></ul><ul><li>Easy* </li></ul>
    13. 13. how do we build “data layers”?
    14. 14. <ul><li>By Hand </li></ul><ul><li>Pros </li></ul><ul><li>POCO </li></ul><ul><li>YAGNI </li></ul><ul><li>No-RTFM </li></ul><ul><li>Cons </li></ul><ul><li>Time </li></ul><ul><li>No FM </li></ul><ul><li>ORM </li></ul><ul><li>Pros </li></ul><ul><li>Time </li></ul><ul><li>Flexible </li></ul><ul><li>Cons </li></ul><ul><li>Learning </li></ul><ul><li>Limits </li></ul><ul><li>Trust* </li></ul>
    15. 15. popular .NET ORMs
    16. 16. DEMO <ul><li>Build data layer with LinqToSql & EF & OpenAccess </li></ul>
    17. 17. data layer patterns <ul><li>Domain Driven Design (DDD) </li></ul><ul><ul><li>Key concepts: Repositories act on model </li></ul></ul><ul><li>ActiveRecord </li></ul><ul><ul><li>Key concepts: Model objects act on themselves </li></ul></ul><ul><li>Data Mapper </li></ul><ul><ul><li>Key concepts: Objects mapped to tables </li></ul></ul>
    18. 18. DEMO <ul><li>Add data access pattern to project </li></ul>
    19. 19. testing the data layer
    20. 20. two testing camps <ul><li>Concepts: </li></ul><ul><li>Test against “real” database </li></ul><ul><li>Use set-up/tear-down code to create test data </li></ul><ul><li>Good When… </li></ul><ul><li>You put lots of logic in your database </li></ul><ul><li>Concepts: </li></ul><ul><li>Test against “fake” database </li></ul><ul><li>Isolates your code from database behavior </li></ul><ul><li>Good When… </li></ul><ul><li>You want fast unit tests and you put most logic in code </li></ul>A Test Database B Mock Database
    21. 21. picking a camp <ul><li>Mocking </li></ul><ul><li>Pros </li></ul><ul><li>Unit test </li></ul><ul><li>Isolate concerns </li></ul><ul><li>Fast </li></ul><ul><li>Cons </li></ul><ul><li>“ Hides” issues </li></ul><ul><li>Does not test database logic </li></ul><ul><li>“ Test” Database </li></ul><ul><li>Pros </li></ul><ul><li>Catches more issues </li></ul><ul><li>Familiar </li></ul><ul><li>Cons </li></ul><ul><li>Slow </li></ul><ul><li>Not a “unit” test </li></ul>
    22. 22. testing considerations <ul><li>What is a unit test? </li></ul><ul><li>What are other types of testing? </li></ul>
    23. 23. UNIT TEST <ul><li>“ Isolated. Repeatable. Fast.” </li></ul>INTEGRATION TEST “ Test interaction between units.” FUNCTIONAL TEST “ Test behavior from user perspective.”
    24. 24. mock testing <ul><li>Goal: Test your business logic </li></ul>B Database Communication (ORM, ADO.NET, etc.) Repository Business Code UI Behaviors Services Database
    25. 25. mocking <ul><li>Stunt doubles for real objects </li></ul><ul><ul><li>Look the same on the outside </li></ul></ul>Mocking Tools: JustMock (by Telerik) Isolator (by TypeMock) MOQ (OSS) RhinoMocks (OSS)
    26. 26. AAA mocking pattern <ul><li>//Arrange </li></ul><ul><li>Set-up your test variables and mocks </li></ul><ul><li>//Act </li></ul><ul><li>Execute your code like normal </li></ul><ul><li>//Assert </li></ul><ul><li>Verify what happened </li></ul>
    27. 27. DEMO: MOCKING DATABASE <ul><li>Testing L2S with Mock Objects </li></ul>
    28. 28. test database <ul><li>Goal: Test your business logic + database behavior </li></ul>A <ul><li>Steps for every test: </li></ul><ul><ul><li>Create database schema + test data </li></ul></ul><ul><ul><li>(Optional) Test database setup correctly </li></ul></ul><ul><ul><li>Execute unit test code </li></ul></ul><ul><ul><li>Verify database behaved correctly </li></ul></ul>
    29. 29. hard parts <ul><li>Creating test schema/data </li></ul><ul><ul><li>DbUnit </li></ul></ul><ul><li>Speed </li></ul><ul><ul><li>In memory database </li></ul></ul><ul><ul><li>SQL Lite, SQL CE, etc. </li></ul></ul>
    30. 30. rules for test database tests <ul><li>Prior to running tests, schema should be redeployed to test DB (+ test data) </li></ul><ul><li>Tests should not change existing data </li></ul><ul><ul><li>Edits, Deletes should be on records created by test </li></ul></ul><ul><ul><li>Original data should be read-only </li></ul></ul><ul><li>Tests should not depend on changes from previous tests </li></ul>
    31. 31. DEMO: TESTING WITH REAL DB <ul><li>Creating integration tests to talk to real database </li></ul>
    32. 32. should you test your DAL?
    33. 33. [email_address] @toddanglin Q & A
    34. 34. Links <ul><li>4GuysFromRolla on Testing DAL (2005) </li></ul><ul><ul><li>http:// </li></ul></ul><ul><li>Unit Testing the DAL (Java, but great discussion of DAL data testing) </li></ul><ul><ul><li>http:// </li></ul></ul><ul><li>Roy Osherove on using Mocks for DAL testing </li></ul><ul><ul><li> </li></ul></ul><ul><li>SQL Lite project page </li></ul><ul><ul><li>http:// </li></ul></ul><ul><ul><li>System.Data.SQLite: / </li></ul></ul><ul><ul><li>http :// / </li></ul></ul><ul><ul><li> </li></ul></ul><ul><li>DbUnit.NET (last updated 2006 – still alpha) </li></ul><ul><ul><li>http:// </li></ul></ul><ul><li>SQL Server Compact 4 CTP1 (2010) </li></ul><ul><ul><li>http:// </li></ul></ul><ul><ul><li>http:// </li></ul></ul><ul><li>SQL Script to clear all tables in database </li></ul><ul><ul><li>http:// </li></ul></ul><ul><li>Microsoft.SqlServer.Management.Smo primer </li></ul><ul><ul><li>http:// </li></ul></ul><ul><ul><li>http:// </li></ul></ul><ul><li>Multi-tier L2S architecture ideas </li></ul><ul><ul><li> </li></ul></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.