advice/feedback sought on testing idea
6 views
Skip to first unread message
Jonathan Vanasco
Jun 3, 2019, 3:18:57 PM6/3/19
to sqlalchemy
We have a fairly complex SqlAlchemy model that spans several integrated applications (300+ tables).
Our text columns are all of the `sqlalchemy.UnicodeText` class, however they all have widely different 'cleaning' or 'sanitization' schemes. This typically needs to be preprocessed, as we need to derive information from these fields before saving - using custom serializers isn't a concern or desire. Right now we have lots of tests - which often duplicate one another and are manually maintained - to ensure everything is processed correctly. A layer of functional tests mocks the data processing for each object - and that's not going to chance. What I'd like to change is the suite of lower unit tests, which mock the various serialization schemes.
I had an idea, and I'm wondering if this is compatible with sane SqlAlchemy usage or not...
I'd like to create a unique subclass of `sqlalchemy.UnicodeText` for each type of data serialization our models use (currently there are 10). The subclasses will simply 'pass', and will just be used by the test suite to auto-detect the desired serialization format and ensure tests pass... and also essentially document what the intended serialization format is.
Does this generally sound okay, or is this likely to screw up the internals? Tests so far show this as not affecting anything negatively.
If anyone else has an idea on a better way to handle this, I'd be excited to learn about it. This just seemed like a low-cost way to simplify our needs for testing and developer documentation.
Our text columns are all of the `sqlalchemy.UnicodeText` class, however they all have widely different 'cleaning' or 'sanitization' schemes. This typically needs to be preprocessed, as we need to derive information from these fields before saving - using custom serializers isn't a concern or desire. Right now we have lots of tests - which often duplicate one another and are manually maintained - to ensure everything is processed correctly. A layer of functional tests mocks the data processing for each object - and that's not going to chance. What I'd like to change is the suite of lower unit tests, which mock the various serialization schemes.
I had an idea, and I'm wondering if this is compatible with sane SqlAlchemy usage or not...
I'd like to create a unique subclass of `sqlalchemy.UnicodeText` for each type of data serialization our models use (currently there are 10). The subclasses will simply 'pass', and will just be used by the test suite to auto-detect the desired serialization format and ensure tests pass... and also essentially document what the intended serialization format is.
Does this generally sound okay, or is this likely to screw up the internals? Tests so far show this as not affecting anything negatively.
If anyone else has an idea on a better way to handle this, I'd be excited to learn about it. This just seemed like a low-cost way to simplify our needs for testing and developer documentation.
Mike Bayer
Jun 3, 2019, 6:41:48 PM6/3/19
to sqlal...@googlegroups.com
On Mon, Jun 3, 2019, at 3:19 PM, Jonathan Vanasco wrote:
> We have a fairly complex SqlAlchemy model that spans several integrated applications (300+ tables).
>
> Our text columns are all of the `sqlalchemy.UnicodeText` class, however they all have widely different 'cleaning' or 'sanitization' schemes. This typically needs to be preprocessed, as we need to derive information from these fields before saving - using custom serializers isn't a concern or desire. Right now we have lots of tests - which often duplicate one another and are manually maintained - to ensure everything is processed correctly. A layer of functional tests mocks the data processing for each object - and that's not going to chance. What I'd like to change is the suite of lower unit tests, which mock the various serialization schemes.
>
> I had an idea, and I'm wondering if this is compatible with sane SqlAlchemy usage or not...
>
> I'd like to create a unique subclass of `sqlalchemy.UnicodeText` for each type of data serialization our models use (currently there are 10).
>
> The subclasses will simply 'pass', and will just be used by the test suite to auto-detect the desired serialization format and ensure tests pass... and also essentially document what the intended serialization format is.
>
> Does this generally sound okay, or is this likely to screw up the internals? Tests so far show this as not affecting anything negatively.
>
> If anyone else has an idea on a better way to handle this, I'd be excited to learn about it. This just seemed like a low-cost way to simplify our needs for testing and developer documentation.
>
>
> 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+...@googlegroups.com.
> To post to this group, send email to sqlal...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sqlalchemy.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/fd95dcf8-7823-4a4f-96b4-134d51eb29d4%40googlegroups.com <https://groups.google.com/d/msgid/sqlalchemy/fd95dcf8-7823-4a4f-96b4-134d51eb29d4%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
Jonathan Vanasco
Jun 3, 2019, 7:00:17 PM6/3/19
to sqlalchemy
On Monday, June 3, 2019 at 6:41:48 PM UTC-4, Mike Bayer wrote:
It's probably better to use TypeDecorator since that keeps the two roles separate. you could also put bind/result handlers on them to assert things if you wanted...
That's a great idea; thank you!. I'll change things in the AM.
So far this technique is working incredibly well. It took a few hours to implement, but quickly solved a handful of outstanding bugs.
* Some model columns each have their own custom class.
* The various create/edit functions have assert statements to ensure the model columns are expected (we run production Python under `-oo`, so `assert` doesn't run)
* A first unittest suite ensures the model has certain columns of a certain type
* A second unittest suite is testing all the different text transformations to ensure we get the right stuff in the right place. (Some columns allow markdown, others allow html, others are plaintext, etc).
This is all in addition to all the unit tests that mock object creation. I needed these tests so slight changes in encoding schemes could be quickly analyzed across dozens of object types. Determining this with functional and integrated tests took minutes to complete the required suites; the new suite runs in a fraction of a second.
* The various create/edit functions have assert statements to ensure the model columns are expected (we run production Python under `-oo`, so `assert` doesn't run)
* A first unittest suite ensures the model has certain columns of a certain type
* A second unittest suite is testing all the different text transformations to ensure we get the right stuff in the right place. (Some columns allow markdown, others allow html, others are plaintext, etc).
This is all in addition to all the unit tests that mock object creation. I needed these tests so slight changes in encoding schemes could be quickly analyzed across dozens of object types. Determining this with functional and integrated tests took minutes to complete the required suites; the new suite runs in a fraction of a second.
Reply all
Reply to author
Forward
0 new messages