TDD as I understand it:
- write tests before you write code- write only enough tests to prove the code works for your use case's defintion of "works"- stop writing code immediately when these tests pass
― π ππ’π¨ (caek), Friday, 10 July 2020 18:09 (four years ago) link
I agree with point 1 (though the practice and theory can be pretty distant IME), point 2 seems nebulous, but point 3 seems like an uncharitable interpretation.
― AxoLOLtl (Leee), Friday, 10 July 2020 18:15 (four years ago) link
since we do mostly services, our version of test-driven is we do OpenApi (swagger, whatever) definitions of the API, someone writes tests against that spec (call a url, validate the returned data is in the expected format and schema, no errors returned) and someone else can code the service at the same timeso you can set up static endpoints with both good/bad data to make sure your tests work properly and then when the actual service is ready you just point it over there and run
― solo scampito (mh), Friday, 10 July 2020 18:16 (four years ago) link
integration tests are only good for spotting erroneous changes and regressions imo, good for big infrastructural open source projects testing code with artificial things is a pain in the ass
The thing that makes me crazy about writing tests is I understand kind of how to write tests for pure functions on data but thatβs only about 5% of any actual application, the other 95% is doing bookkeeping with resources like databases and external services and god knows what, setting up mock everything just to test that stuff feels tautological and maddening. I just canβt.
― all cats are beautiful (silby), Friday, 10 July 2020 18:19 (four years ago) link
I agree with point 1 (though the practice and theory can be pretty distant IME), point 2 seems nebulous, but point 3 seems like an uncharitable interpretation.β AxoLOLtl (Leee), Friday, July 10, 2020 2:15 PM (two minutes ago) bookmarkflaglink
β AxoLOLtl (Leee), Friday, July 10, 2020 2:15 PM (two minutes ago) bookmarkflaglink
i don't understand if you're agreeing/disagreeing with these practicies, or with the claim that they describe TDD.
― π ππ’π¨ (caek), Friday, 10 July 2020 18:20 (four years ago) link
Point 1 is an accurate description of TDD, though my adherence to it is not complete.Point 3 does not accurately describe TDD, IMO. In my practice, I'll write the easy tests first, then as edge cases crop up, add appropriate tests (though I probably add it to the code before I add these scenarios to the test suite).
― AxoLOLtl (Leee), Friday, 10 July 2020 18:29 (four years ago) link
well sure point 3 elides the fact that it's supposed to be a loop in which you get the tests to pass, then add more tests, then get the new tests to pass by writing more code, add more tests, etc.
but the point (and the definition of TDD AFAICT) is that you're supposed to stop writing code on this iteration as soon as the tests pass. you may opt to refactor (and you have tests so that should be easy). but you're done implementing new *features* or *behaviours* until you write more tests.
that's part of the *definition* of TDD AFAICT (based on the wikipedia page haha), and it's certainly consistent with the practice of TDD according to koogs' pairing partner: "That commit doesn't really feel like the minimum required to make the test pass. It's jumping ahead too far."
― π ππ’π¨ (caek), Friday, 10 July 2020 18:38 (four years ago) link
an example of one of his implementations.
method takes a structure containing a value and two flags. if either flag is true return the value.
so the tests were something like
structure.value = 2retval = test(structure, true, false)assertEquals(2, retval)structure.value = 3retval = test(structure, false, true)assertEquals(3, retval)
structure.value = 3retval = test(structure, false, true)assertEquals(3, retval)
and his implementation was
if flag1 return 2if flag2 return 3
which just seems perverse when you could've written
if [flag1 || flag2] return structure.value
and be done with it.
― koogs, Friday, 10 July 2020 18:41 (four years ago) link
or is that "jumping ahead too far"?
― koogs, Friday, 10 July 2020 18:44 (four years ago) link
it's not always insane to overtest simple code because:
1. tests are incredibly valuable if/when you refactor/add features later2. the easiest time to write tests is when the implementation is on your mental stack, not months later, and definitely not if someone else did the implementation.
*that* is insane though.
― π ππ’π¨ (caek), Friday, 10 July 2020 18:46 (four years ago) link
Itβs definitely perverse to write a wrong implementation just because it passes your first stab on a test
Actually I think Iβm going to throw up
― all cats are beautiful (silby), Friday, 10 July 2020 18:52 (four years ago) link
Like does this guy ever want to get anything done in his life
― all cats are beautiful (silby), Friday, 10 July 2020 18:53 (four years ago) link
If this is the kind of mind that TDD produces then TDD is bad for your mind
― all cats are beautiful (silby), Friday, 10 July 2020 18:54 (four years ago) link
these two chapters of dive into python (nominally about unit testing but not really) actually make me like TDD
https://diveinto.org/python3/unit-testing.htmlhttps://diveinto.org/python3/refactoring.html
― π ππ’π¨ (caek), Friday, 10 July 2020 18:57 (four years ago) link
In koogs's example, I think that the way to DRY it up would be to write a method like
has_flag
flag1 || flag2
Then in the calling function stub/mock has_flag.
Agreed on both caek's latest two points, and point 2 is particularly why I advocate a TDD (or TDD-lite?) approach.
As to the "dictionary" definition of TDD, that's why I never call myself a strict follower; I do feel that using testing as a framework for development is incredibly valuable, especially with setup and tear-down, and as a prompt for writing modular code.
― AxoLOLtl (Leee), Friday, 10 July 2020 18:58 (four years ago) link
(oh, irl the flags weren't parameters, they were flags in another structure and this second structure was mocked and passed in
test1when(mockObj.getflag1()).doreturn(true)retval = test(structure, mockObj)...test2when(mockObj.getflag2()).doreturn(true)retval = test(structure, mockObj)
so not possible to combine them, sorry
in fact i cheated by checking in two failing tests at the same time, which is apparently verboten, just to try and cut down the number of iterations)
― koogs, Friday, 10 July 2020 19:08 (four years ago) link
the other 95% is doing bookkeeping with resources like databases and external services and god knows what, setting up mock everything just to test that stuff feels tautological and maddening. I just canβt+ ui interaction, and otm.
― neith moon (ledge), Friday, 10 July 2020 19:59 (four years ago) link
i mean i've tried (not v hard) and failed (for various reasons, that being one) to get tdd or any kind of testing culture implemented at our company. and I'm ok with that.
― neith moon (ledge), Friday, 10 July 2020 20:04 (four years ago) link
tdd seems a reach for a company that does not have a testing culture
― π ππ’π¨ (caek), Friday, 10 July 2020 20:09 (four years ago) link
i'm jealous of all of you
― Two Meter Peter (Ste), Friday, 10 July 2020 20:19 (four years ago) link
xp yeah true, baby steps, but i can't even see how to do those as it doesn't seem worth testing the small bits of fuctionality that haven't got db or ui interaction all over them.
― neith moon (ledge), Friday, 10 July 2020 20:19 (four years ago) link
i don't have any major issue with TDD as a philosophy, but pairing with a TDD pedant like koogs described sounds like my own personal hell
― the portentous pepper (govern yourself accordingly), Saturday, 11 July 2020 11:31 (four years ago) link
i'm not arguing against testing in any sense, but projecting your own orthodoxy onto a pairing partner kinda defeats the purpose of pairing imo!
― the portentous pepper (govern yourself accordingly), Saturday, 11 July 2020 11:36 (four years ago) link
Absolute psycho replies to this one
my favorite reason to write software is money— Abby Fuller (@abbyfuller) July 10, 2020
― π ππ’π¨ (caek), Saturday, 11 July 2020 21:10 (four years ago) link
Ugh, Iβll take your word for it. Sheβs right of course.
― all cats are beautiful (silby), Saturday, 11 July 2020 21:10 (four years ago) link
galaxy brain:
and this should be the only reason. money is the best way to transform ideas to value and benefit all in the end. other reasons like freedom, morale or noble purpose can't last long enough and may lead to the opposite.— Andrew Zhu (@xhinker) July 11, 2020
― neith moon (ledge), Sunday, 12 July 2020 06:57 (four years ago) link
Wow
― all cats are beautiful (silby), Sunday, 12 July 2020 07:10 (four years ago) link
God, fuck programmers
― all cats are beautiful (silby), Sunday, 12 July 2020 07:11 (four years ago) link
Weβre not all bad.
― Mr. Snrub, Sunday, 12 July 2020 13:17 (four years ago) link
https://www.youtube.com/watch?v=pp4suZ4jNXg
― Lipstick O.G. (James Redd and the Blecchs), Sunday, 12 July 2020 13:36 (four years ago) link
All bad including me
― all cats are beautiful (silby), Sunday, 12 July 2020 13:42 (four years ago) link
Every line of code is a brick in the edifice of fascism, or something.
― all cats are beautiful (silby), Sunday, 12 July 2020 13:43 (four years ago) link
The best code is no code at all
― Lipstick O.G. (James Redd and the Blecchs), Sunday, 12 July 2020 13:46 (four years ago) link
Bob Marley
― Lipstick O.G. (James Redd and the Blecchs), Sunday, 12 July 2020 13:47 (four years ago) link
Or Vonnegut
― Lipstick O.G. (James Redd and the Blecchs), Sunday, 12 July 2020 13:48 (four years ago) link
Giving a talk on that exact thesis in a couple weeks
― all cats are beautiful (silby), Sunday, 12 July 2020 13:52 (four years ago) link
gotta love unit tests with inputs such as
new byte[] { 0x27, 00, 00, 00, (byte) 0xFF, (byte) 0b11_0_1_0_0_1_0 }
― koogs, Sunday, 12 July 2020 16:06 (four years ago) link
(this actually my forte, have been extracting bits from bytes since i had a zx81)
― koogs, Sunday, 12 July 2020 16:08 (four years ago) link
DEAD BEEF BAD FOOD
― Lipstick O.G. (James Redd and the Blecchs), Sunday, 12 July 2020 16:49 (four years ago) link
I've got a great poke for Jet Set Willy.
― Being cheap is expensive (snoball), Sunday, 12 July 2020 17:03 (four years ago) link
Lol
― Isolde mein Herz zum Junker (James Redd and the Blecchs), Tuesday, 14 July 2020 17:36 (four years ago) link
Donβt know if itβs a religion thing but why do some people hate to do a git rebase and then do a fast-forward merge.
― Isolde mein Herz zum Junker (James Redd and the Blecchs), Tuesday, 14 July 2020 17:38 (four years ago) link
we banned merge commits on our project because of one guy
― π ππ’π¨ (caek), Tuesday, 14 July 2020 17:39 (four years ago) link
Not surprised. Did the graph look like the one shone here in The Problem? https://mtyurt.net/post/git-using-advanced-rebase-features-for-a-clean-repository.html
― Isolde mein Herz zum Junker (James Redd and the Blecchs), Tuesday, 14 July 2020 18:36 (four years ago) link
Can you lock out all merges? We have fast-forward-only some branches but then I recently noticed that some of the more unenlightened just merge that branch into theirs and then they can fast-forward this merged melange back.
― Isolde mein Herz zum Junker (James Redd and the Blecchs), Tuesday, 14 July 2020 18:38 (four years ago) link
I missed out on the TDD conversation but I wanted to mention that my one experience pairing with a TDD disciple involved watching her create a bunch of tests that were logically incorrect, getting them to pass, and missing giant pieces of logic that interconnected subsystems of the module we were working on and actively mocking other pieces of functionality we were supposed to be testing, so technically we wrote passing code according to the tests but, because the tests weren't actually right, the whole thing was super buggy and caused a bunch of later rework.
I know this isn't the fault of TDD per se but it did play into a lot of my preconceived notions against it.
Re: merge commits, I don't see why anyone should care what I do on my feature branch as long as I squash-merge into the main branch.
― shout-out to his family (DJP), Tuesday, 14 July 2020 18:49 (four years ago) link
Yeah we donβt care what you do on feature branches but main (nee master) is ff only enforced via our code review thing (gerrit). What this means in practice is you hit βmergeβ and gerrit rebased your change into the tip of main then merged by ff. if thereβs a conflict you have to resolve it and resubmit the review. We used to let people do that without running the tests but the number of people who committed the string β>>>>>>>>>β was getting out of hand so it has to at least build after a manually resolved merge conflict.
― π ππ’π¨ (caek), Tuesday, 14 July 2020 18:55 (four years ago) link
Doowatchyalike, just don't create a twelve-lane merge superhighway and then (DEAD) BEEF when your merges ultimately break down.
― Isolde mein Herz zum Junker (James Redd and the Blecchs), Wednesday, 15 July 2020 13:55 (four years ago) link
https://www.destroyallsoftware.com/blog/2017/the-biggest-and-weirdest-commits-in-linux-kernel-git-history
― all cats are beautiful (silby), Wednesday, 15 July 2020 15:17 (four years ago) link