Downloaded 518 times
Uploaded byDavid Wheeler
Unit Test Your Database
The document discusses the importance of unit testing within database management, specifically using PostgreSQL. It addresses common misconceptions about testing, such as it being time-consuming or unnecessary, and advocates for test-driven development as a solution. The content includes examples of how to implement tests through SQL commands and modifications to ensure code reliability.
In this document
Powered by AI
The slide addresses common misconceptions about database testing, emphasizing the necessity of unit tests despite perceived complexities.This slide outlines test conception challenges including difficulty and irrelevance experienced by developers.
Describes the TDD process using a Fibonacci calculator example, illustrating how to write tests first.
Demonstration of executing basic SQL tests to ensure functionality through the PostgreSQL interface.
Focus on establishing a simple function and running tests to ensure accurate outputs, detailing the process of modifications.
Explains the significance of adding assertions in tests to validate expected outcomes against actual results.
Introduces regression testing for maintaining a functional codebase and ensuring previously fixed bugs do not resurface.
Details assertions for integrity tests on database schemas and to ensure features meet required standards.
The use of SQL functions to dynamically query the database based on user-provided parameters and return results.
Focuses on refactoring existing database functions for optimal performance while maintaining functionality.
Discusses transitioning existing database functions into SQL, ensuring both improved performance and maintainability.
Focuses on the importance of consistent testing for stable and reliable systems, addressing misconceptions about tests.
Concludes by encouraging developers to embrace testing methodologies, referencing tools available for efficient testing.
![[Pgday.Seoul 2020] SQL Tuning](https://cdn.slidesharecdn.com/ss_thumbnails/pgday-201117134901-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Editor's Notes
- #5 The development priorities argument.
- #6 The focus argument.
- #7 The everything-by-hand argument
- #8 The domain responsibility argument.
- #9 The “the app is the test” argument.
- #10 The relevancy argument.
- #11 The “it’s just a one line change” argument.
- #12 The complexity argument.
- #13 Which is a general rejection of the idea of glassbox testing, ie. that all tests must be regression tests.
- #14 The Mathematician’s argument.
- #15 The flow and iteration argument
- #16 The forsight argument.
- #17 The “it just works” argument.
- #18 The competence argument.
- #19 Okay, you have me there.
- #20 Okay, you have me there.
- #213 Red flag for “this function does too much” and “this function is too tightly coupled.”
- #214 Red flag for “this function does too much” and “this function is too tightly coupled.”
- #215 Red flag for “this function does too much” and “this function is too tightly coupled.”
- #216 Red flag for “this function does too much” and “this function is too tightly coupled.”
- #217 Red flag for “this function does too much” and “this function is too tightly coupled.”
- #218 Red flag for “this function does too much” and “this function is too tightly coupled.”
- #219 Red flag for “this function does too much” and “this function is too tightly coupled.”
- #255 Rejection of glassbox testing, that is, that all tests must be regression tests.
- #256 Rejection of glassbox testing, that is, that all tests must be regression tests.
- #257 Rejection of glassbox testing, that is, that all tests must be regression tests.
- #258 Rejection of glassbox testing, that is, that all tests must be regression tests.