I'm unit testing my database-driven application using the technique laid out here: http://alextechrants.blogspot.com/2013/08/unit-testing-sqlalchemy-apps.html
One thing I've struggled with for years now is managing mock data. Some things I've tried: * Populating the database with hand-written mock data before the tests run It's hard to make the mock data comprehensive. Adding and modifying data is difficult because it will often break tests. Data is often unrealistic. * Populating the database with deterministic pseudorandom mock data before tests run. A lot of noise in the mock data. Makes tests more robust, but more difficult to sift through data to write the tests. Refactoring the data generator script often causes massive changes to the data. * Mock data specific to each test A lot of boilerplate in populating non-nullable fields that aren't relevant to the tests. Even more boilerplate to populate dependent relations. e.g., to add a row to `shift` you need an `employee`, for an `employee` you need a `company`, ... * Mock data factories to populate data specific to each test. A la Factory Boy. Currently trying this out, too early to tell how it will work out. What have your experiences been with this? What strategies do you employ? -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
