Object factory for Django

Overview

Model Bakery: Smart fixtures for better tests

Model Bakery offers you a smart way to create fixtures for testing in Django. With a simple and powerful API you can create many objects with a single line of code.

Model Bakery is a rename of the legacy Model Mommy project.

Tests Latest PyPI version Documentation Status

Install

pip install model_bakery

Usage and Info

Basic usage

# models.py

class Customer(models.Model):
    enjoy_jards_macale = models.BooleanField()
    name = models.CharField(max_length=30)
    email = models.EmailField()
    age = models.IntegerField()
    bio = models.TextField()
    days_since_last_login = models.BigIntegerField()
    birthday = models.DateField()
    last_shopping = models.DateTimeField()

# test_models.py

from django.test import TestCase
from model_bakery import baker
from pprint import pprint

class TestCustomerModel(TestCase):
    def setUp(self):
        self.customer = baker.make('shop.Customer')
        pprint(self.customer.__dict__)

"""
{'_state': <django.db.models.base.ModelState object at 0x1129a3240>,
 'age': 3841,
 'bio': 'vUFzMUMyKzlnTyiCxfgODIhrnkjzgQwHtzIbtnVDKflqevczfnaOACkDNqvCHwvtWdLwoiKrCqfppAlogSLECtMmfleeveyqefkGyTGnpbkVQTtviQVDESpXascHAluGHYEotSypSiHvHzFteKIcUebrzUVigiOacfnGdvijEPrZdSCIIBjuXZMaWLrMXyrsUCdKPLRBRYklRdtZhgtxuASXdhNGhDsrnPHrYRClhrSJSVFojMkUHBvSZhoXoCrTfHsAjenCEHvcLeCecsXwXgWJcnJPSFdOmOpiHRnhSgRF',
 'birthday': datetime.date(2019, 12, 3),
 'enjoy_jards_macale': True,
 'id': 1,
 'last_shopping': datetime.datetime(2019, 12, 3, 21, 42, 34, 77019),
 'name': 'qiayYnESvqcYLLBzxpFOcGBIfnQEPx',
 'days_since_last_login': 6016}
"""

Check out documentation for more complete examples.

Contributing

Detailed info here.

Maintainers

Creator

Comments
  • Ability to load custom fields for Model Mommy to also generate

    Ability to load custom fields for Model Mommy to also generate

    I'd like to be able to load a custom fields list to model_mommy so that Models with these fields can also be generated.

    Maybe this is similar to a Recipe but it would be a one time config load of fields that comply to an interface potentially, and then mommy.make(MyModelWithACustomField) would be able to still generate the Model instance. Thus avoiding the error: <Field> is not supported by mommy

    opened by aaronlelevier 19
  • [BUG] v1.2.1 breaks usage of baker.make(related_model__field=value)

    [BUG] v1.2.1 breaks usage of baker.make(related_model__field=value)

    Specifying field values of related model instances within the baker.make() signature (e.g. baker.make(my_related_model__field=value) is not possible anymore with v1.2.1. This still works in v1.2.0.

    Expected behavior

    The model instance AND its required related model instances should be created, populated with random defaults except the values we explicitly passed in the call.

    Actual behavior

    ValueError: Cannot assign "<fk-id>": "<model>.<fk-field>" must be a "<fk-model>" instance.

    Reproduction Steps

    Try creating a model instance with baker.make() using related field assignments for an FK field that has a default value/callable returning an ID as seen in the following example. Any related models will do, these are just for illustration:

    # models.py
    
    def get_default_category():
        """ 
        Returning an ID here will make model_bakery fail, returning an instance is fine, but see:
        https://docs.djangoproject.com/en/3.1/ref/models/fields/#django.db.models.Field.default 
        """
        return 1
    
    
    class SpotCategory(models.Model):
        name = models.CharField(max_length=128)
    
    
    class TVSpot(models.Model):
        category = models.ForeignKey(SpotCategory, on_delete=models.CASCADE, default=get_default_category)
    
    
    # tests.py
    
    class TestBugWithModelBakeryVersion_1_2_1:
    
        def test_creating_related_models_separately_works(self, db):
            """This seems to always work, no matter the version of model_bakery."""
    
            category = baker.make("SpotCategory", name="Special")
            baker.make("TVSpot", category=category)
    
        def test_specifying_related_model_fields_within_constructor_fails_with_v1_2_1(
            self, db
        ):
            """This worked up until 1.2.0, but fails with 1.2.1 as follows:
    
            ValueError: Cannot assign "1990": "TVSpot.category" must be a "SpotCategory" instance.
    
            """
            baker.make("TVSpot", category__name="Special")
    
    

    Run tests with different model_bakery versions like:

    
    $ pip install model_bakery==1.2.0 && pytest -k TestBugWithModelBakeryVersion_1_2_1  # should pass
    $ pip install model_bakery==1.2.1 && pytest -k TestBugWithModelBakeryVersion_1_2_1  # should fail
    
    

    Versions

    OS: Ubuntu 20.04 Database: MySQL 5.7.32 Python: 3.8 Django: 2.2.17 pytest: 6.1.2 Model Bakery: 1.2.1

    Maybe you do have an idea which of the changes in 1.2.1 is related to this. Let me know what I can do to help fix this, thanks.

    bug 
    opened by cb109 13
  • Add support for iterators as m2m kwargs

    Add support for iterators as m2m kwargs

    As detailed in https://github.com/model-bakers/model_bakery/issues/129, you cannot pass iterators for m2m kwargs when creating objects. Iterators may be useful when you've created a set of objects, and want to assign them one-by-one to the M2M fields of another list of objects.

    This changes the behavior such that the iterator is iterated for each object being created, leaving the M2M's with one object each:

    class Foo(Model):
        pass
    
    class Bar(Model):
        foos = models.ManyToManyField(Foo)
    
    # Foos in this case may either be 'made' or 'prepared'
    foos = baker.make(Foo, _quantity=3)
    bars = baker.make(Bar, _quantity=3, foos=iter(foos))
    
    bars[0].foos.first() == foos[0]
    bars[1].foos.first() == foos[1]
    bars[2].foos.first() == foos[2]
    
    opened by ghost 12
  • Wrong typehinting in Recipe init

    Wrong typehinting in Recipe init

    The typehinting in the init method of Recipe is wrong. It states that _model is supposed to be str - but it can be an instance of django model as well.

    Expected behavior

    from typing import Union
    from django.db import models
    class Recipe(object):
        def __init__(self, _model: Union[str, models.Model], **attrs) -> None:
    

    Actual behavior

    class Recipe(object):
        def __init__(self, _model: str, **attrs) -> None:
    

    Reproduction Steps

    PyCharm will always show an error if I pass a model class to the Recipe. That is quite annoying and misleading.

    Versions

    Python: 3.8 Django: 3.1.2 Model Bakery: 1.2.0

    Thanks!

    opened by GitRon 12
  • Add a Python code formatter

    Add a Python code formatter

    We should add Black to enforce some code styles to improve legibility and maintenance.

    • [x] Add Black as a development requirement
    • [x] Add it to the pre-commit config
    good first issue 
    opened by berinhard 11
  • Refactor `QueryCount` usage to use `assertNumQueries` instead

    Refactor `QueryCount` usage to use `assertNumQueries` instead

    The existing QueryCount test utility class was implemented without the knowledge of an existing django built-in way of asserting that a certain number of database queries were performed.

    The following code snippet is an example of an existing use of QueryCount:

    def test_bulk_create_multiple_one_to_one(self):
        queries = QueryCount()
    
        with queries.start_count():
            baker.make(models.LonelyPerson, _quantity=5, _bulk_create=True)
            assert queries.count == 6
    
        assert models.LonelyPerson.objects.all().count() == 5
        assert models.Person.objects.all().count() == 5
    

    The next code snippet is what it could look like using the provided assertNumQueries:

    def test_bulk_create_multiple_one_to_one(self):
        with self.assertNumQueries(6):
            baker.make(models.LonelyPerson, _quantity=5, _bulk_create=True)
    
        assert models.LonelyPerson.objects.all().count() == 5
        assert models.Person.objects.all().count() == 5
    

    Then the QueryCount class can be removed entirely.

    good first issue 
    opened by timjklein36 10
  • Using

    Using "related" to map model_set to recipe creates duplicate entries in the db

    'related' keyword doesn't seem to function properly: 2 model instances are persisted in the db, the first one bypassing the recipe (completely random), the other respecting the recipe.

    Expected behavior

    only 1 model instance should be persisted in the db.

    Actual behavior

    first created model instance does not apply anything from the recipe (random). second created model instance correctly applies the recipe.

    Reproduction Steps

    I have the following recipes:

    default_equipment = Recipe(Equipment, constructor_code="abc", eurotax_group="def", is_visible=True)
    default_tires = Recipe(Tires, rim_size=50, tire_wall=50, tire_width=50)
    default_vehicle = Recipe(
        Vehicle,
        registration_date=date.today,
        is_registered=True,
        mileage=10000,
        equipment_set=related(default_equipment),
        tires=foreign_key(default_tires),
    )
    

    If I comment out the 'equipment_set =' line, everything works as expected -> only one model instance is persisted with the values defined in the recipe.

    edit

    more strange behaviour: if I create multiple instances from the recipe:

        vehicle = baker.make_recipe("django_apps.vehicle.default_vehicle", _quantity=2)
    

    then, 3 instances are created. The first two vehicles are not created with the values from the recipe, but the 3rd one is correct. That is really strange behaviour.

    If I omit the "related" in the recipe, and pass the equipments directly, no issue:

    equipments = baker.prepare_recipe("django_apps.vehicle.default_equipment", _quantity=2)
    vehicle = baker.make_recipe("django_apps.vehicle.default_vehicle", equipment_set=equipments)
    

    Bottom line: I think bakery, using the "related" keyword, creates an empty vehicle when creating the equipments, then assigns the newly created vehicle to those equipments, leaving the old vehicles in the db (which were created randomly)

    I think this behaviour is quite confusing if I am correct...

    Versions

    Python: 3.8.1 Django: 3.1.1 Model Bakery: 1.1.1 pytest-django = "==3.9.0" => I do not use django tests, but the pytest-django plugin @pytest.mark.django_db annotation

    opened by majorgilles 10
  • AttributeError: 'ManyToManyRel' object has no attribute 'has_default'

    AttributeError: 'ManyToManyRel' object has no attribute 'has_default'

    After update from 1.3.2 to 1.3.3 started getting exception from title.

    Sorry I didn't debug properly this issue and can't say why this is happening but my best guess would be because of this change https://github.com/model-bakers/model_bakery/compare/1.3.2...1.3.3#diff-e5857deb915e241f429a0c118e89e06a3388d3ce1466e3aa4b960b7055172b6dL322

    Expected behavior

    Baker.get_fields() 1.3.2 version
    (
        <django.db.models.fields.AutoField: id>,
        <django.db.models.fields.related.ForeignKey: group>,
        <django.db.models.fields.related.ManyToManyField: service_lines>,
    )
    

    Actual behavior

    Baker.get_fields() 1.3.3 version
    {
        <django.db.models.fields.AutoField: id>,
        <django.db.models.fields.related.ForeignKey: group>,
        <django.db.models.fields.related.ManyToManyField: service_lines>,
        <ManyToManyRel: myapp.foo1>,  # I guess it not suppose to be here
    }
    

    And as a result of new element from Baker.get_fields()

    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    /python3.8/site-packages/model_bakery/baker.py:89: in make
        return [
    /python3.8/site-packages/model_bakery/baker.py:90: in <listcomp>
        baker.make(
    /model_bakery/baker.py:324: in make
        return self._make(**params)
    /model_bakery/baker.py:371: in _make
        self.model_attrs[field.name] = self.generate_value(
    
    >       if field.has_default() and field.name not in self.rel_fields:
    E       AttributeError: 'ManyToManyRel' object has no attribute 'has_default'
    
    /model_bakery/baker.py:566: AttributeError
    

    Reproduction Steps

    I don't think that model that I use has any custom behavior and it's just because of how Baker.get_fields() works in new 1.3.3 version

    Models that I use anyway

    class Foo(models.Model):
        slug = models.SlugField("Service line slug", unique=True, max_length=150)
        name = models.CharField("Service line name", max_length=150, null=True)
    
    class Foo1(models.Model):
        bars = models.ManyToManyField("myapp.Bar")
    
    class Bar(models.Model):
        foo = models.ManyToManyField("myapp.Foo", related_name="foos")
    
    baker.make("core.Bar", _quantity=3, slug=cycle(["1", "2", "3"]), _fill_optional=True)
    

    Versions

    Python: 3.8.10 Django: 2.2.24 Model Bakery: 1.3.3

    bug high priority 
    opened by a-edakin 9
  • Use of itertools.count to generate record ids in Recipe

    Use of itertools.count to generate record ids in Recipe

    Hi,

    itertools.count does not seem to be working in recipe or in a direct make statement

    when I declare:

    import itertools as it
    baker.make('Play',  puzzle_id=it.count(start=1), _quantity=7)
    

    or fake_play = Recipe(Play, puzzle_id=it.count(start=1))

    I expected puzzle_id to take incremental values 1,2,3, ... 7

    Instead, I receive an error message:

    TypeError: int() argument must be a string, a bytes-like object or a number, not 'itertools.count'

    I have tried different things but I don't really see what is happening as itertools.cycle is working well.

    There seem to be nothing on the internet about it, not on the documentation. So I would assume it normally works

    Could you help me out?

    Versions

    Python:Python 3.7.4 Django: 2.2.7 Model Bakery:1.0.2

    bug 
    opened by formacube 8
  • Replace timezone code by Django's built in solution

    Replace timezone code by Django's built in solution

    Model Bakery has a module to deal with timezones that was implemented before Django had a built in support for it. We should replace it by the timezone API from Django 1.11.

    https://github.com/model-bakers/model_bakery/blob/c2b609f6b065e587cf4a2e4253b518634d4995b3/model_bakery/timezone.py

    Expected behavior

    This lib should use Django's built in timezone library instead of bakery's timezone module.

    Things I could think of:

    • [ ] Replace calls to smart_datetime
    • [ ] Replace calls to tz_aware
    • [ ] Replace calls to now
    • [ ] Replace calls to utc
    • [ ] Delete bakery's timezone module
    enhancement good first issue 
    opened by anapaulagomes 8
  • Using an iterator/generator to populate a GenericForeignKey field when creating many instances with _quantity fails

    Using an iterator/generator to populate a GenericForeignKey field when creating many instances with _quantity fails

    A TypeError is produced when creating multiple model instances using baker.make() with the _quantity param, and the model in question has a GenericForeignKey field where an iterator or generator is passed to baker.make as the value for the GenericForeignKey field.

    Expected behavior

    Values yielded by the iterator/generator should become the successive field values for each of the instances created by baker.make() for a GenericForeignKey field as with other fields.

    Actual behavior

    A TypeError is produced.

    The reason is that this line (https://github.com/model-bakers/model_bakery/blob/main/model_bakery/baker.py#L362) only handles iterator parameters when they exist on fields in model._meta.fields or model._meta.many_to_many, however a GenericForeignKey field exists on model._meta.private_fields instead (since it's a virtual field). Consequently, next() is never called on the iterator/generator and as a result, the iterator/generator itself is ultimately passed as the field value when constructing the model, producing a TypeError since that's an incorrect value type for the field.

    Reproduction Steps

    # models.py
    
    class MyModel(models.Model):
        content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
        object_id = models.PositiveIntegerField()
        myfield = GenericForeignKey()
    
    # Any model for the purpose of relating generically to MyModel
    class OtherModel(models.Model):
        ...
    
    ...
    
    objs = baker.make('OtherModel', _quantity=2)
    # This line produces TypeError: MyModel() got an unexpected keyword argument 'myfield'
    baker.make('MyModel', myfield=iter(objs), _quantity=2)
    

    Versions

    Python: 3.9.1 Django: 3.1.7 Model Bakery: 1.2.1

    bug 
    opened by abbottc 7
  • Feature request: Support setting random seed for repeatable test runs

    Feature request: Support setting random seed for repeatable test runs

    If a test run fails intermittently due to random data satisfying certain conditions it is useful to be able to set/use the random seed for repeatability and debugging purposes. This is common with other testing packages (ex. faker) and would be a nice addition to baker.

    In the meantime, perhaps it is sufficient to force the random seed used by python at tests start? Ref: https://github.com/model-bakers/model_bakery/blob/a408873f032dc2eeafc88291f3518396602b7742/model_bakery/random_gen.py#L17

    enhancement 
    opened by nefrob 1
  • forward _create_files flag in relational generators

    forward _create_files flag in relational generators

    Describe the change

    given a django model with a foreign-key to a related model containing a FileField, I would like to just generate an instance and have model_bakery create the file on the child model if required.

    PR Checklist

    • [x] Change is covered with tests
    • [x] CHANGELOG.md is updated
    opened by hiaselhans 0
  • PEP 621: Migrate from setup.py and setup.cfg to pyproject.toml

    PEP 621: Migrate from setup.py and setup.cfg to pyproject.toml

    Describe the change Migrate setup.py to setup.cfg using setuptools-py2cfg plus manual modifications. Then migrate setup.cfg to pyproject.toml using ini2toml to do the file conversion and running pyproject-fmt and then validate-pyproject in pre-commit to validate the results.

    • Currently, flake8 is not yet compatible with pyproject.toml so put its config into the file .flake8.

    PR Checklist

    • [ ] Change is covered with tests
    • [x] CHANGELOG.md is updated
    opened by cclauss 7
  • Mazulo/adds faker generator feature

    Mazulo/adds faker generator feature

    Describe the change

    Currently we're using some random data to feed the fields. In this PR I'm proposing an approach where the user can enable an extra feature by adding _use_faker_generator=True when using baker.make. When enabled, we will use Faker to generate the data. For now we only have a small list but it can grow as needed:

    • username
    • email
    • first_name
    • last_name
    • name
    • fullname
    • full_name
    • ip
    • ipv4
    • ipv6

    I think this is a really interesting feature because it will provide the users to have a more realistic data to work on.

    PR Checklist

    • [X] Change is covered with tests
    • [X] CHANGELOG.md is updated
    opened by mazulo 1
  • FileField and ArrayField not generated with random data when default=None or default=list

    FileField and ArrayField not generated with random data when default=None or default=list

    Describe the issue

    Generating random data is not working below the condition. ArrayField with default=list FileField with default=None

    To Reproduce

    class A(models.Model):
        career = ArrayField(models.CharField(max_length=30), default=list)
        main_image = models.ImageField(blank=True, null=True, default=None)
    
    a = baker.make(A, _fill_optional=True, _create_files=True)
    print(a.career, a.main_image)
    
    [], None
    

    Expected behavior ArrayField and FileField should be filled with random data.

    Versions

    • Python: 3.10.3
    • Django: 4.1.2
    • Model Bakery: 1.8.0
    opened by legshort 0
  • baker.make tries to set a field that is a foreign key on ContentType that something that doesn't exist.

    baker.make tries to set a field that is a foreign key on ContentType that something that doesn't exist.

    Describe the issue As part of testing an abstract model, within the tests, we create a dummy model which is used for testing and then is later dropped. This dummy model represents a view.

    In other models we have fields which are a foreign key on the content type model. The problem arises when we try to use baker.make to create an instance of that model. Most of the time it works fine, but sometimes, baker tries to set the content type field to the dummy view content type we had previously dropped.

    To Reproduce models.py

    from django.db import models
    from django.contrib.contenttypes.models import ContentType
    
    
    class MyModel(models.Model):
        related_object_type = models.ForeignKey(
            to=ContentType,
            on_delete=models.PROTECT,
        )
    

    Within the tests somewhere:

    class TestUserMatView:
       
        username = models.CharField(max_length=64)
        
        class Meta:
            db_table = "test_user_mat_view"
            managed = False
    
        @classmethod
        def create_view(cls) -> None:
            cls.drop_view()  # Ensures any previous creations will be torn down.
            with connection.cursor() as cursor:
                cursor.execute(
                    """CREATE MATERIALIZED VIEW IF NOT EXISTS %s
                    AS SELECT * FROM auth_user;
                    """,
                    [AsIs(cls._meta.db_table)],
                )
                cursor.execute(
                    "CREATE UNIQUE INDEX ON %s (username);",
                    [AsIs(cls._meta.db_table)],
                )
    
        @classmethod
        def drop_view(cls) -> None:
            with connection.cursor() as cursor:
                cursor.execute(
                    "DROP MATERIALIZED VIEW IF EXISTS %s",
                    [AsIs(cls._meta.db_table)],
                )
    

    Create some tests that involve running TestUserMatView.create_view and then later TestUserMatView.drop_view (to clean). Then, create tests where we use baker.make(MyModel). This should work a couple of times, but at some point, there should be an error that moans about the table test_user_mat_view not existing.

    Expected behavior It should create the instance without a hitch.

    Versions

    • Python: 3.9.5
    • Django: 3.2.11
    • Model Bakery: 1.0.0 (we can't use a newer version due to a memory leak issue that I've raised).
    opened by Salaah01 1
Releases(1.9.0)
  • 1.9.0(Oct 24, 2022)

    What's Changed

    • [#322] Fix seq for timezone-aware start value by @timjklein36 in https://github.com/model-bakers/model_bakery/pull/353
    • Fix #298 -- create m2m when using _bulk_create=True by @amureki in https://github.com/model-bakers/model_bakery/pull/354
    • [dev] Use official postgis docker image in CI by @amureki in https://github.com/model-bakers/model_bakery/pull/355

    Full Changelog: https://github.com/model-bakers/model_bakery/compare/1.8.0...1.9.0

    Source code(tar.gz)
    Source code(zip)
  • 1.8.0(Oct 13, 2022)

    What's Changed

    • Fix #349 -- subtract lists in Baker.get_fields() instead of casting to set by @amureki in https://github.com/model-bakers/model_bakery/pull/352

    Full Changelog: https://github.com/model-bakers/model_bakery/compare/1.7.1...1.8.0

    Source code(tar.gz)
    Source code(zip)
  • 1.7.1(Oct 5, 2022)

    What's Changed

    • fix future deprecate warning of django.utils.timezone.utc by @jairhenrique in https://github.com/model-bakers/model_bakery/pull/339
    • docs: Fix a few typos by @timgates42 in https://github.com/model-bakers/model_bakery/pull/345

    Dependencies

    • Bump pycodestyle from 2.9.0 to 2.9.1 by @dependabot in https://github.com/model-bakers/model_bakery/pull/344
    • Bump flake8 from 5.0.3 to 5.0.4 by @dependabot in https://github.com/model-bakers/model_bakery/pull/343
    • Bump black from 22.6.0 to 22.8.0 by @dependabot in https://github.com/model-bakers/model_bakery/pull/342
    • Bump pytest from 7.1.2 to 7.1.3 by @dependabot in https://github.com/model-bakers/model_bakery/pull/350
    • Bump mypy from 0.971 to 0.981 by @dependabot in https://github.com/model-bakers/model_bakery/pull/351

    Full Changelog: https://github.com/model-bakers/model_bakery/compare/1.7.0...1.7.1

    Source code(tar.gz)
    Source code(zip)
  • 1.7.0(Aug 2, 2022)

    Changed

    • Fixed a bug with overwritten _save_kwargs and other custom arguments PR #330

    Dependencies

    • Bump pillow from 9.1.1 to 9.2.0 by @dependabot in https://github.com/model-bakers/model_bakery/pull/331
    • Bump black from 22.3.0 to 22.6.0 by @dependabot in https://github.com/model-bakers/model_bakery/pull/333
    • Bump pip-tools from 6.6.2 to 6.8.0 by @dependabot in https://github.com/model-bakers/model_bakery/pull/332
    • Bump pycodestyle from 2.8.0 to 2.9.0 by @dependabot in https://github.com/model-bakers/model_bakery/pull/334
    • Bump mypy from 0.961 to 0.971 by @dependabot in https://github.com/model-bakers/model_bakery/pull/335
    • Bump flake8 from 4.0.1 to 5.0.2 by @dependabot in https://github.com/model-bakers/model_bakery/pull/336
    • Bump pre-commit from 2.19.0 to 2.20.0 by @dependabot in https://github.com/model-bakers/model_bakery/pull/337
    • Bump flake8 from 5.0.2 to 5.0.3 by @dependabot in https://github.com/model-bakers/model_bakery/pull/338

    Full Changelog: https://github.com/model-bakers/model_bakery/compare/1.6.0...1.7.0

    Source code(tar.gz)
    Source code(zip)
  • 1.6.0(Jun 26, 2022)

    Added

    • Python 3.11 support PR #327
    • Django 4.1 support PR #327
    • Added documentation for callables, iterables, sequences PR #309

    Changed

    • [dev] Replace changelog reminder action with a custom solution that can ignore Dependabot PRs PR #328

    Removed

    New Contributors

    • @magdumsuraj07 made their first contribution in https://github.com/model-bakers/model_bakery/pull/309

    Full Changelog: https://github.com/model-bakers/model_bakery/compare/1.5.0...1.6.0

    Source code(tar.gz)
    Source code(zip)
  • 1.5.0(Apr 5, 2022)

    Added

    Changed

    • Extend type hints in model_bakery.recipe module, make Recipe class generic PR #292
    • Explicitly add _fill_optional parameters to baker.make and baker.prepare to aid IDE autocomplete function. PR #264
    • Fixed errors with reverse M2M relationships PR #299
    • Fixed errors with reverse M2O relationships PR #300
    • Improve exception message for unknown field types PR #301
    • Fixed random generation of ContentType values when there is no database access #290
    Source code(tar.gz)
    Source code(zip)
  • 1.4.0(Jan 4, 2022)

    Added

    • Added postgis version to test settings
    • Add support for Python 3.10 PR #244
    • Support for Django 4.0 PR #236

    Changed

    • Validate increment_by parameter of seq helper when value is an instance of datetime PR #247
    • Fix a simple typo in bulk_create disclaimer in docs PR #245
    • Allow relation _id fields to use sequences PR #253
    • Fix bulk_create not working with multi-database setup PR #252
    • Conditionally support NullBooleanField, it's under deprecation and will be removed in Django 4.0 PR #250
    • Fix Django max version pin in requirements file PR #251
    • Improve type hinting to return the correct type depending on _quantity usage PR #261

    Removed

    • Drop official Django 3.1 support. Django 2.2 is still supported, and 3.1 will likely keep working, but it’s not tested PR #236

    New Contributors

    • @bnjmn made their first contribution in https://github.com/model-bakers/model_bakery/pull/245
    • @jairhenrique made their first contribution in https://github.com/model-bakers/model_bakery/pull/244
    • @ashiazed made their first contribution in https://github.com/model-bakers/model_bakery/pull/251
    • @SmileyChris made their first contribution in https://github.com/model-bakers/model_bakery/pull/261

    Full Changelog: https://github.com/model-bakers/model_bakery/compare/1.3.3...1.4.0

    Source code(tar.gz)
    Source code(zip)
  • 1.3.3(Oct 8, 2021)

    Added

    • _bulk_create flag is not populating related objects as well PR #206
    • Add support for iterators on GFK fields when using _quantity param PR #207
    • Add support for iterators on many-to-many fields PR#237

    Changed

    • Fix typos in Recipes documentation page PR #212
    • Add venv to ignored folders of flake8 and pydocstyle PR#214
    • Run flake8 after code modifications when linting PR#214
    • Add typing for baker.make and baker.prepare PR#213
    Source code(tar.gz)
    Source code(zip)
  • 1.3.2(Jun 13, 2021)

  • 1.3.1(Apr 24, 2021)

Code coverage measurement for Python

Coverage.py Code coverage testing for Python. Coverage.py measures code coverage, typically during test execution. It uses the code analysis tools and

Ned Batchelder 2.3k Jan 04, 2023
FFPuppet is a Python module that automates browser process related tasks to aid in fuzzing

FFPuppet FFPuppet is a Python module that automates browser process related tasks to aid in fuzzing. Happy bug hunting! Are you fuzzing the browser? G

Mozilla Fuzzing Security 24 Oct 25, 2022
This repository contnains sample problems with test cases using Cormen-Lib

Cormen Lib Sample Problems Description This repository contnains sample problems with test cases using Cormen-Lib. These problems were made for the pu

Cormen Lib 3 Jun 30, 2022
Test django schema and data migrations, including migrations' order and best practices.

django-test-migrations Features Allows to test django schema and data migrations Allows to test both forward and rollback migrations Allows to test th

wemake.services 382 Dec 27, 2022
Webscreener is a tool for mass web domains pentesting.

Webscreener is a tool for mass web domains pentesting. It is used to take snapshots for domains that is generated by a tool like knockpy or Sublist3r. It cuts out most of the pentesting time by scree

Seekurity 3 Jun 07, 2021
Integration layer between Requests and Selenium for automation of web actions.

Requestium is a Python library that merges the power of Requests, Selenium, and Parsel into a single integrated tool for automatizing web actions. The

Tryolabs 1.7k Dec 27, 2022
pytest plugin to test mypy static type analysis

pytest-mypy-testing — Plugin to test mypy output with pytest pytest-mypy-testing provides a pytest plugin to test that mypy produces a given output. A

David Fritzsche 21 Dec 21, 2022
This project demonstrates selenium's ability to extract files from a website.

This project demonstrates selenium's ability to extract files from a website. I've added the challenge of connecting over TOR. This package also includes a personal archive site built in NodeJS and A

2 Jan 16, 2022
Instagram unfollowing bot. If this script is executed that specific accounts following will be reduced

Instagram-Unfollower-Bot Instagram unfollowing bot. If this script is executed that specific accounts following will be reduced.

Biswarup Bhattacharjee 1 Dec 24, 2021
A Library for Working with Sauce Labs

Robotframework - Sauce Labs Plugin This is a plugin for the SeleniumLibrary to help with using Sauce Labs. This library is a plugin extension of the S

joshin4colours 6 Oct 12, 2021
Python script to automatically download from Zippyshare

Zippyshare downloader and Links Extractor Python script to automatically download from Zippyshare using Selenium package and Internet Download Manager

Daksh Khurana 2 Oct 31, 2022
Bayesian A/B testing

bayesian_testing is a small package for a quick evaluation of A/B (or A/B/C/...) tests using Bayesian approach.

Matus Baniar 35 Dec 15, 2022
A mocking library for requests

httmock A mocking library for requests for Python 2.7 and 3.4+. Installation pip install httmock Or, if you are a Gentoo user: emerge dev-python/httm

Patryk Zawadzki 452 Dec 28, 2022
AutoExploitSwagger is an automated API security testing exploit tool that can be combined with xray, BurpSuite and other scanners.

AutoExploitSwagger is an automated API security testing exploit tool that can be combined with xray, BurpSuite and other scanners.

6 Jan 28, 2022
Headless chrome/chromium automation library (unofficial port of puppeteer)

Pyppeteer Pyppeteer has moved to pyppeteer/pyppeteer Unofficial Python port of puppeteer JavaScript (headless) chrome/chromium browser automation libr

miyakogi 3.5k Dec 30, 2022
The definitive testing tool for Python. Born under the banner of Behavior Driven Development (BDD).

mamba: the definitive test runner for Python mamba is the definitive test runner for Python. Born under the banner of behavior-driven development. Ins

Néstor Salceda 502 Dec 30, 2022
Compiles python selenium script to be a Window's executable

Problem Statement Setting up a Python project can be frustrating for non-developers. From downloading the right version of python, setting up virtual

Jerry Ng 8 Jan 09, 2023
This is a simple software for fetching new changes to remote repositories automatically.

Git Autofetch Git Autofetch is a simple software for fetching new changes from a repo to local repositories after a set time interval. This program is

Shreyas Ashtamkar 10 Jul 21, 2022
Active Directory Penetration Testing methods with simulations

AD penetration Testing Project By Ruben Enkaoua - GL4Di4T0R Based on the TCM PEH course (Heath Adams) Index 1 - Setting Up the Lab Intallation of a Wi

GL4DI4T0R 3 Aug 12, 2021
Connexion-faker - Auto-generate mocks from your Connexion API using OpenAPI

Connexion Faker Get Started Install With poetry: poetry add connexion-faker # a

Erle Carrara 6 Dec 19, 2022