[](https://travis-ci.org/internap/jabstract)
# Welcome unit testers!
## That's not cool:
```
def test_something():
api_response = {
"field1": "value1",
"field2": "value2",
....
"field37": "value37",
....
"field7632": "value7632"
}
myapi.return_value = api_response
result = production_code()
assert result == "value37"
```
^ This is annoying if your `production_code` method only uses field37 right?
Of course you could only define the field37 in your test but if a log or something else irrelevant to THIS test uses another field, it has to be there even if it's irrelevant to THIS test.
## That's prettier:
```
api_response = jabstract({
"field1": "value1",
"field2": "value2",
....
"field37": "value37",
....
"field7632": "value7632"
})
def test_something():
myapi.return_value = api_response(field37="value37")
result = production_code()
assert result == "value37"
```
^ The test is so much more beautiful!
# USAGE
Declare your json responses somewhere:
```
from jabstract import jabstract
api_response = jabstract({
... json-ish payload ...
})
```
Then use it in your tests by defining only relevant fields:
```
.return_value = api_response(
key=value
)
```
It even supports complex payloads!
```
api_response = jabstract({
"client": {
"name": "John doe",
"email": "johndoe@example.org"
}
})
.return_value = api_response(
client=dict(name="Foobar")
)
```
\* note that `response["client"]["email"]` will keep its default value.
# Best practices
Tests using jabstracted payload should define only what is relevant to the test, not less, not more, so that it is obvious to the human eye where a value come from
let's test this code
```
def name_getter(payload):
return payload["client"]["name"]
```
## **Good** example:
```
api_response = jabstract({
"client": {
"name": "John doe",
"email": "johndoe@example.org"
}
})
def test_name_getter():
payload = api_response(client=dict(name="Baboon 2.0"))
assert name_getter(payload) == "Baboon 2.0"
```
**Reviewer says** : Ohhh so it takes the name of the client from the payload... +2
## ~~BAD~~ example
```
api_response = jabstract({
"client": {
"name": "John doe",
"email": "johndoe@example.org"
}
})
def test_name_getter():
payload = api_response()
assert name_getter(payload) == "John doe"
```
**Reviewer says** : Who the hell is john doe... click on payload... ahhh i see... meh, +1
# Welcome unit testers!
## That's not cool:
```
def test_something():
api_response = {
"field1": "value1",
"field2": "value2",
....
"field37": "value37",
....
"field7632": "value7632"
}
myapi.return_value = api_response
result = production_code()
assert result == "value37"
```
^ This is annoying if your `production_code` method only uses field37 right?
Of course you could only define the field37 in your test but if a log or something else irrelevant to THIS test uses another field, it has to be there even if it's irrelevant to THIS test.
## That's prettier:
```
api_response = jabstract({
"field1": "value1",
"field2": "value2",
....
"field37": "value37",
....
"field7632": "value7632"
})
def test_something():
myapi.return_value = api_response(field37="value37")
result = production_code()
assert result == "value37"
```
^ The test is so much more beautiful!
# USAGE
Declare your json responses somewhere:
```
from jabstract import jabstract
api_response = jabstract({
... json-ish payload ...
})
```
Then use it in your tests by defining only relevant fields:
```
.return_value = api_response(
key=value
)
```
It even supports complex payloads!
```
api_response = jabstract({
"client": {
"name": "John doe",
"email": "johndoe@example.org"
}
})
.return_value = api_response(
client=dict(name="Foobar")
)
```
\* note that `response["client"]["email"]` will keep its default value.
# Best practices
Tests using jabstracted payload should define only what is relevant to the test, not less, not more, so that it is obvious to the human eye where a value come from
let's test this code
```
def name_getter(payload):
return payload["client"]["name"]
```
## **Good** example:
```
api_response = jabstract({
"client": {
"name": "John doe",
"email": "johndoe@example.org"
}
})
def test_name_getter():
payload = api_response(client=dict(name="Baboon 2.0"))
assert name_getter(payload) == "Baboon 2.0"
```
**Reviewer says** : Ohhh so it takes the name of the client from the payload... +2
## ~~BAD~~ example
```
api_response = jabstract({
"client": {
"name": "John doe",
"email": "johndoe@example.org"
}
})
def test_name_getter():
payload = api_response()
assert name_getter(payload) == "John doe"
```
**Reviewer says** : Who the hell is john doe... click on payload... ahhh i see... meh, +1
Metadata
Release files for jabstract 0.1.3
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| jabstract-0.1.3.tar.gz | 8.1 kB | Without provenance | Details |
Release files / jabstract-0.1.3.tar.gz
| Download URL | jabstract-0.1.3.tar.gz |
|---|---|
| Size | 8.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
0ce86fffc005d6d11b878d2e779fae310b839d556958c71d2e0e0453e78a2da5
|
|
BLAKE2b-256 checksum How to use checksums |
039fd1c4df3c2951dc9f5681d02515b3a42db4588740c51e54dddd49d1d2908d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/1.12.1 pkginfo/1.5.0.1 requests/2.21.0 setuptools/40.8.0 requests-toolbelt/0.9.1 tqdm/4.30.0 CPython/3.5.6
|
Security for jabstract 0.1.3
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.