#django

with django projects, you often have a lot of declarative code, and thus you can very very easily reach 100% branch coverage without actually testing very much

i am totally guilty of this :p

that's not a bad thing

less code = less places to go wrong

the bad thing here is the false sense of security

of course, it doesn't test that it does what you _want_

coverage of X% only tells you, "we have no idea what (100-X)% of our code is doing"

i should listen to my inner jessamynsmith more often ;)

Koterpillar: that is pithy

is there a pip command which will install a dep and record it in requirements.txt?

Koterpillar: you should tweet it (or I will!)

yes, I do not like false sense of security

Koterpillar: :)

morenoh149: pip install <stuff> && pip freeze

morenoh149: you should update requirements.txt by hand, it isn't hard.

I'm just used to --save-dev in npm

morenoh149: consider pip-tools

and --save

morenoh149: pip freeze has good and bad points

since a few months, my projects enforce 100% branch coverage in the build. it is a little shocking to realize how easy you can get 100% branch coverage with really crappy tests ;)

morenoh149: it is nice, and would be nice if pip did similarl

oh!

moldy: I don't enforce 100% for that very reason

I feel like such a noob rn

moldy: jessamynsmith's point is the key: running the code is useless without good verification of the results.

Ladies and gents, I'm running into a weird issue I'm not sure how to solve. I have a model, like User, that has a 1-1 relationship with a Profile. On my URL routes, I want to be able to do something like /user/1/profile, but when I plug that into my routes it breaks saying that /user/{pk}/profile{pk} is an invalid redefinition of PK. Ideas?

jessamynsmith: my reasoning is that 100% crappy coverage is still better than 99% crappy coverage ;)

nedbat: why the second {pk}?

I like honest coverage, whatever the percent

but my actual reason is that it just forces us to write at least some tests :p

heh

it's a lame way of disciplining myself, but it works

Koterpillar: mis-nick?

what?

Koterpillar: There is no second PK. It's like Django is expecting that there would be a second PK, as a detail or something. It's not in the URL conf path regex at all.

relaxing the 100% coverage requirement feels like defeat, so i rather write that test :p

Koterpillar: nm

nedbat: ah, yes, sorry

jwarren_: post your URLconf line

Koterpillar: router.register(r'user/(?P<pk>\d+)/profile', ProfileViewSet)

moldy: the downside of 100% coverage is, your code ends up littered by #pragma statements

jwarren_: I bet ProfileViewSet adds a {pk} to the end of whatever you give it

(I'm using Django Rest Framework if that makes any diff)

jwarren_: it totally does

jwarren_: not familiar with DRF but maybe there's a way to configure how ViewSets insert the /{pk} bit

moldy: I require pylint 10, for example, and sometimes that means a lot of pragmas

Got it, thanks Koterpillar

Koterpillar: i don't know pylint 10, but yeah, i enforce flake8 and even isort on my build :p

FYI pylint can be configured to act like isort

nedbat: awake? am getting odd results with coverage, showing my template tags are never run

FunkyBob: let's look at it!

on github... django sniplates...

TDD is such a heavy influence on so many tutorials and coding in general it seems, yet i'm having a hard time adapting my thinking to it >.<

FunkyBob: if you have a link to the repo and the coverage results, that will help

pilne: any partiuclar aspect?

pilne: hugely rewarding

nedbat: i agree that verification should be done, but to my defense: even just running the code is still better than not running it at all ;) you get the implicit verification that it doesn't throw an exception

pilne: so is quickcheck

if it is just 'testing is hard', it just is

moldy: sure, but there's nothing left to tell you where to add better tests.

just updated coverage, but your django templates coverage plugin won't install : http://dpaste.com/29ZC8NH

and esp when you dn't have a clear idea of where you are going

no, it isn't testing is hard... but.. years ago when i first learned to code, you wrote the tests after a function, and i'm still more in that mindset

i had a long hiatus... last time i coded (before picking it up again recently) was when java 1.2 was the new hotness

pilne: yeah, get out of it - you'll be tempted to write tests that succeed

you should write tests that fail

FunkyBob: that's not mine. You want django_coverage_plugin

oh, ok

nedbat: true. but then again, with frameworks like django, it is sometimes rather unclear where to draw the line.

FunkyBob: (I had to look up the name again!)

yep, that went in fine

nedbat: yeah, I was guessing too :)

i understand that Koterpillar, i truly do, i just can't seem to figure out how to get into that mindset

nedbat: so, all tests run, and pass... but...

nedbat: you can test many CBVs by just importing the module. otoh, if you functional-test them, you test mostly framework code, not your own.

pretend that your function is already written, but by me, and I'm evil

moldy: you test framework code + your _configuration_

Koterpillar: or incompetent :)

so, figure out what i want the function to do, everything it shouldn't do, write tests to verify these things, then create the function?

that's the theory

we explaining TDD to pilne ?

yes?

FunkyBob: how can i see the results?

One school of thought is the point of TDD isn't testing, it's design

okay, four levels: things it should normally do, things it must not do (hard cases?), incompetent mistakes, evil behavior

if something is easy to test, it is usually pretty decoupled

^

Koterpillar: yes, but you have to draw the line somewhere, and it's not always entirely obvious where to draw it

moldy: you usually have external requirements

moldy: if your requirement is "build some views that don't crash", fine

Koterpillar: i can get the first two in my head easily, but the last two... especially the last one, i'm not confident in my ability to "think of" before it bites me in the ass

pilne: that'll do. You can iterate on this: make tests, write the code to pass them - but be lazy here :)

e.g. if your test of (+) is 2+2 = 4, write it as "return 4"

Koterpillar: i am more thinking about things like authentication / permissions, that can be quite easy to break with declarative code without either your tests noticing or coverage going down

moldy: I will generally point at quickcheck but I'm not sure it will be suitable to testing something this large

for me, a big part of testing is not "do i meet the requirements", but rather "did this change break anything that i did not expect it to break" :=

i never have requirements that can be turned into tests anyway :p

hmm, never? example?

Koterpillar: i basically never have written requirements, and if i have them, they are all lies

and they change every time i ask for clarification

how do you convince people that you've fulfilled them then?

willpower

how do you convince _yourself_ that you've fulfilled them then?

Koterpillar: i usually don't

never underestimate the power of self-delusion

heh

i just let stuff run and wait for complaints

requirements are a big myth :p

it's a silly phantasy. as if the customer wrote the test cases, and if you pass them, you did your job. maybe some people work like that, but i dare to say 99% of us don't :p

somewhere between that and "reproduce a week of incoming TCP packets with identical results" the truth lies