I don't like doctests to test code either, but what I really love them for is to test documentation. I almost always use them in my READMEs, to make sure that my documentation isn't out of sync with my latest code changes. I find it's a great tool for API or library documentation. I include all markdown/rst files in my pytest runs by default, and there's very little extra work (When I write presentation slides, I do it in markdown as well, and my code examples get checked for free.) Writing them is not always trivial, especially when parts of your output are non-deterministic, but being able to validate documentation is definitely worth it to me.
The past few years I don't get to spend much time doing Python anymore, and having testable documentation is a feature I've missed in pretty much every other language.
@@anthonywritescode True, definitely not worth it for unit testing where code changes frequently. If your documentation uses examples at the API level, and you're committed to not breaking backwards compatibility, you should only very rarely have to write or change the doctests there, though. If you were going to use code examples in there anyway, the extra overhead isn't that high to verify that they are and stay correct.
Personally, i think doctests aren't a good testing tool, but if you have a REPL example in your documentation (which is needed sometimes), being 100% sure that your documentation examples are correct is nice.
that's fair, I think there's better ways to do that though (and I still think that REPL examples are bad because you can't copy paste them and run them)
Why don't you use black, if I may ask? :) I am not always happy using it, but for sure worry about trivial stuff much less. Do you use a different code formatter, or none at all?
I don't like many of the decisions black makes -- I use ~5-6 other formatters which achieve a similar goal without the decisions I disagree with (add-trailing-comma, double-quote-string-fixer, autopep8, pyupgrade, reorder-python-imports)
I don't like doctests to test code either, but what I really love them for is to test documentation. I almost always use them in my READMEs, to make sure that my documentation isn't out of sync with my latest code changes. I find it's a great tool for API or library documentation. I include all markdown/rst files in my pytest runs by default, and there's very little extra work (When I write presentation slides, I do it in markdown as well, and my code examples get checked for free.) Writing them is not always trivial, especially when parts of your output are non-deterministic, but being able to validate documentation is definitely worth it to me.
The past few years I don't get to spend much time doing Python anymore, and having testable documentation is a feature I've missed in pretty much every other language.
yeah I mean there's certainly some positives there -- but it's just so much work to get those positives
@@anthonywritescode True, definitely not worth it for unit testing where code changes frequently. If your documentation uses examples at the API level, and you're committed to not breaking backwards compatibility, you should only very rarely have to write or change the doctests there, though. If you were going to use code examples in there anyway, the extra overhead isn't that high to verify that they are and stay correct.
Sweet, never knew this existed! Almost like a testing layer "below" unit tests... although I'd be scared to see what people try and shoehorn into this
I've seen some wild doctests heh
Personally, i think doctests aren't a good testing tool, but if you have a REPL example in your documentation (which is needed sometimes), being 100% sure that your documentation examples are correct is nice.
that's fair, I think there's better ways to do that though (and I still think that REPL examples are bad because you can't copy paste them and run them)
what alternative would you use for such examples?
normal code blocks are much easier to copy paste
> oh by the way, _ is saved
(matlab flashbacks intensify)
Great content... can you make video for the traditional testing?
there are several if you search the channel
@@anthonywritescode ok
@@anthonywritescode is the traditional unittest
Why don't you use black, if I may ask? :) I am not always happy using it, but for sure worry about trivial stuff much less. Do you use a different code formatter, or none at all?
I don't like many of the decisions black makes -- I use ~5-6 other formatters which achieve a similar goal without the decisions I disagree with (add-trailing-comma, double-quote-string-fixer, autopep8, pyupgrade, reorder-python-imports)
@@anthonywritescode Ah thanks, makes sense :)
@@anthonywritescode why don't u like those decisions? just curious
dude you are just the best
Just how many clones do you have?
all of them