Passed
Push — master ( d45a38...7b5bde )
by Swen
03:34
created

test_get_prep_value()   A

Complexity

Conditions 2

Size

Total Lines 12

Duplication

Lines 0
Ratio 0 %

Importance

Changes 1
Bugs 0 Features 1
Metric Value
cc 2
c 1
b 0
f 1
dl 0
loc 12
rs 9.4285
1
import pytest
2
3
from psqlextra.fields import HStoreField
4
5
6
def test_deconstruct():
7
    """Tests whether the :see:HStoreField's deconstruct()
8
    method works properly."""
9
10
    original_kwargs = dict(uniqueness=['beer', 'other'])
11
    _, _, _, new_kwargs = HStoreField(**original_kwargs).deconstruct()
0 ignored issues
show
Coding Style introduced by
Usage of * or ** arguments should usually be done with care.

Generally, there is nothing wrong with usage of * or ** arguments. For readability of the code base, we suggest to not over-use these language constructs though.

For more information, we can recommend this blog post from Ned Batchelder including its comments which also touches this aspect.

Loading history...
12
13
    for key, value in original_kwargs.items():
14
        assert new_kwargs[key] == value
15
16
17
@pytest.mark.parametrize('input,output', [
18
    (dict(key1=1, key2=2), dict(key1='1', key2='2')),
19
    (dict(key1='1', key2='2'), dict(key1='1', key2='2')),
20
    (dict(key1=1, key2=None, key3='3'), dict(key1='1', key2=None, key3='3')),
21
    ([1, 2, 3], ['1', '2', '3']),
22
    (['1', '2', '3'], ['1', '2', '3']),
23
])
24
def test_get_prep_value(input, output):
0 ignored issues
show
Bug Best Practice introduced by
This seems to re-define the built-in input.

It is generally discouraged to redefine built-ins as this makes code very hard to read.

Loading history...
25
    """Tests whether the :see:HStoreField's get_prep_value
26
    method works properly."""
27
28
    assert HStoreField().get_prep_value(input) == output
29