Programming as a career

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.

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 time

so 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

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.

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

i don't understand if you're agreeing/disagreeing with these practicies, or with the claim that they describe TDD.

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).

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."

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 = 2
retval = test(structure, true, false)
assertEquals(2, retval)
structure.value = 3
retval = test(structure, false, true)
assertEquals(3, retval)

and his implementation was

if flag1 return 2
if flag2 return 3

which just seems perverse when you could've written

if [flag1 || flag2] return structure.value

and be done with it.

or is that "jumping ahead too far"?

it's not always insane to overtest simple code because:

1. tests are incredibly valuable if/when you refactor/add features later
2. 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.

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

Like does this guy ever want to get anything done in his life

If this is the kind of mind that TDD produces then TDD is bad for your mind

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.html
https://diveinto.org/python3/refactoring.html

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.

(oh, irl the flags weren't parameters, they were flags in another structure and this second structure was mocked and passed in

test1
when(mockObj.getflag1()).doreturn(true)
retval = test(structure, mockObj)
...
test2
when(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
)

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.

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.

tdd seems a reach for a company that does not have a testing culture

i'm jealous of all of you

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.

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

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!

Absolute psycho replies to this one

my favorite reason to write software is money

— Abby Fuller (@abbyfuller) July 10, 2020

Ugh, I’ll take your word for it. She’s right of course.

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

Wow

God, fuck programmers

We’re not all bad.

https://www.youtube.com/watch?v=pp4suZ4jNXg

All bad including me

Every line of code is a brick in the edifice of fascism, or something.

The best code is no code at all

Bob Marley

Or Vonnegut

Giving a talk on that exact thesis in a couple weeks

gotta love unit tests with inputs such as

new byte[] { 0x27, 00, 00, 00, (byte) 0xFF, (byte) 0b11_0_1_0_0_1_0 }

(this actually my forte, have been extracting bits from bytes since i had a zx81)

DEAD BEEF BAD FOOD

I've got a great poke for Jet Set Willy.

Lol

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.

we banned merge commits on our project because of one guy

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

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.

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.

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.

Doowatchyalike, just don't create a twelve-lane merge superhighway and then (DEAD) BEEF when your merges ultimately break down.

https://www.destroyallsoftware.com/blog/2017/the-biggest-and-weirdest-commits-in-linux-kernel-git-history

Thanks.

Also, I misspelled Doowutchyalike.