--- title: "Data Layer Testing: Test Inheritance Patterns" url: "https://osherove.com/blog/2007/11/28/data-layer-testing-test-inheritance-patterns.md" canonical: "https://osherove.com/blog/2007/11/28/data-layer-testing-test-inheritance-patterns.html" published: "2007-11-28T18:56:51" updated: "2007-11-28T18:56:51" tags: ["Agile", "Agile Related", "Art Of Unit Testing", "Testing Guidelines", "Unit Testing", "altnetconf"] author: "Roy Osherove" description: "I'm preparing for my tutorial on Database and Data Layer unit testing that I will be giving at the Agile Practices Conference next week. It's always nice to have a full 3 hours to get pretty deep into something. 75…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Data Layer Testing: Test Inheritance Patterns By Roy Osherove November 28, 2007 In [Agile](https://osherove.com/blog/category/agile), [Agile Related](https://osherove.com/blog/category/agile-related), [Art Of Unit Testing](https://osherove.com/blog/category/art-of-unit-testing), [Testing Guidelines](https://osherove.com/blog/category/testing-guidelines), [Unit Testing](https://osherove.com/blog/category/unit-testing), [altnetconf](https://osherove.com/blog/category/altnetconf) **Historical article** · Originally published November 28, 2007; technical details may be outdated. I'm preparing for my tutorial on Database and Data Layer unit testing that I will be giving at the Agile Practices Conference  next week. It's always nice to have a full 3 hours to get pretty deep into something. 75 minutes just isn't enough to grasp a concept deeply enough, just to graze it around the edges. When writing data layer tests, there are several patterns I've noticed, especially around the notion of inheritance within the test classes (Abstract test class pattern).  I've observed at least three different patterns emerging from inheritance that I've personally used, all relating to data layer testing, but could be used elsewhere: **Abstract Utility Class** ![image](https://osherove.com/img/wb/p.net_blogs_rosherove_WindowsLiveWriter_DataLayerTestingTestInheritancePatterns_3770_image_thumb.png) This class will usually be a base class for tests written for data layer objects. it would contain "facilities" such as database helper classes, setup and teardown methods that would automatically rollback any test and anything else a derived base class that was testing a data layer object would need (helper methods for asserting complex stuff, for example). This is a classic "Abstract test class" pattern, and the next two are built on top of it. **Template Test Class** ![image](https://osherove.com/img/wb/net_blogs_rosherove_WindowsLiveWriter_DataLayerTestingTestInheritancePatterns_3770_image_thumb_1.png)The template test class will contain _abstract_ methods as unit tests, which any derived class would have to override and perform. That means that if you are always testing the same things against a data layer object (insert returns different IDs, update works etc...) test authors on new data layer classes who derive from this class will never forget to implement at least these basic tests. they would also get the facilities for doing assertions and other things from the base class, as depicted in the previous pattern. makes sure you don't forget tests, saves some time on the infrastructure. **Abstract Driver Test Class** ![image](https://osherove.com/img/wb/net_blogs_rosherove_WindowsLiveWriter_DataLayerTestingTestInheritancePatterns_3770_image_thumb_2.png) This class will have _non abstract_ test case methods inside it that will always run the same way. these test methods will call (using abstract methods) to the derived class' implementation of type specific actions (insert specific for a category, or update specific to person) . That leaves the derived class to only implement very basic things such as insert (and return the ID), update, or delete (by ID). the test methods in the base class will do the rest of the work. derived classes don't need to implement any tests unless they want to add type specific tests which don't belong on the base class. in the image to the left the green methods are tests that the base class runs, and the yellow ones are type specific helpers that the derived class has to implement. this makes writing tests for a new data layer object (as long as its interface is the same) very simple by inheriting a test class and implementing a few methods. all the test permutations in the base class will then run on the data layer object. saves lots of time and forgetting tests. What patterns have you come across? ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Dec 18, 2007 ### [Basic Guidelines for using RowTest and data driven tests](https://osherove.com/blog/2007/12/18/basic-guidelines-for-using-rowtest-and-data-driven-tests.html) - Dec 18, 2007 ### [\[RowTest\] for NUnit, File System Interfaces for unit testing](https://osherove.com/blog/2007/12/18/rowtest-for-nunit-file-system-interfaces-for-unit-testing.html) - Nov 21, 2007 ### [\[Songs\] Every Build You Break, Reflection](https://osherove.com/blog/2007/11/21/songs-every-build-you-break-reflection.html) - Nov 17, 2007 ### [Mocking LINQ Queries, Extension methods and Anonymous Types](https://osherove.com/blog/2007/11/17/mocking-linq-queries-extension-methods-and-anonymous-types.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/