324 / 478
$
rm accounts/migrations/0001_initial.py
$
python3 manage.py makemigrations
System check identified some issues:
[...]
Migrations for 'accounts':
0001_initial.py:
- Create model User
That gets the tests passing, although they are still giving us some warnings:
$
python3 manage.py test accounts
[...]
System check identified some issues:
WARNINGS:
accounts.User: (auth.W004) 'User.email' is named as the 'USERNAME_FIELD', but
it is not unique.
[...]
Ran 12 tests in 0.041s
OK
Tests as Documentation
Let’s go all the way and make the email field into the primary key, and thus implicitly
remove the auto-generated
id
column.
Although that warning is probably enough of a justification to go ahead and make the
change, it would be better to have a specific test:
accounts/tests/test_models.py (ch16l043).
def
test_email_is_primary_key
(
self
):
user
=
User
()
self
.
assertFalse
(
hasattr
(
user
,
'id'
))
It’ll help us remember if we ever come back and look at the code again in future.
self.assertFalse(hasattr(user, 'id'))
AssertionError: True is not false
Your tests can be are a form of documentation for your code—they
express what your requirements are of a particular class or function.
Sometimes, if you forget why you’ve done something a particular way,
going back and looking at the tests will give you the answer. That’s
why it’s important to give your tests explicit, verbose method names.
And here’s the implementation (feel free to check what happens with
unique=True
first):
accounts/models.py (ch16l044).
=
models
.
EmailField
(
primary_key
=
True
)
296
|
Chapter 16: Server-Side Authentication and Mocking in Python