5 ms·
> I have been taking advantage of a persistently running python instance and sending code snippets to it as a quick way to explore the data and ... deleting 90%
by berkes 5y ago
> I have been taking advantage of a persistently running python instance and sending code snippets to it as a quick way to explore the data and ... deleting 90% of them anyway
How is that different from TDD other than the name "test" vs "snippet"? Tests are excellent tools to explore an API or a dataset. Tests are perfect for quick automation.
And, most importantly: tests, like any code, should be constantly and consistently get refactored. So throwing 90% away is expected and perfectly fine. Just like I expect you'll write 110x as much production code than what ends in production in the end: it's quite common for me to write 200+ lines over hours, only to end up with a five-line diff in the final commit.
- gpderetta 5y ago> How is that different from TDD other than the name "test" vs "snippet Lack of ceremony. Lack of assertions. No separate test cases. If any quick throwaway hacky code count as a test for the purposes of TDD, then sure, but it kind of waters down the meaning of tests.
- berkes 5y ago> but it kind of waters down the meaning of tests. From the C2Wiki: > UnitTests are programs written to run in batches and test classes. Each typically sends a class a fixed message and verifies it returns the predicted answer. Which already is very "watery" afaik. And a snippet that verifies something does X, fits this perfectly. Your approach may "violate" many other testing- best-practices and even "rules", such as "tests should verify only one thing" or "each branch should have one test" or "tests may only go through public interfaces" and whatnot, but I consider it TDD, as long as the scripts and snippets are written before any code. And if written afterwards, it counts as automated testing, though with a broad definition of "automated, I guess.
- gpderetta 5y agoWell, I expect the snippets to run and possibly uncover bugs, so the underlying code is already written (or is written at the same time). I run them manually but I keep a log and I periodically rerun them. So I guess it is not TDD but semi-automated testing (or better, an interactive way to end up with automated tests).