Programming as a career

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.

It's pulled, and it's fine, but there's clearly a balance between "octopus merges are fine" and "Christ, that's not an octopus, that's a Cthulhu merge".

I would just like to take a moment to say javascript sucks and lodash sucks and _.times REALLY sucks

Why does every fucking thing have to be a function, how about you () => juggle(myBalls)

Not only does it all have to be a function but there’s a strong convention that functions be anonymous whenever possible because fuck the reader, right?

Isn’t most of lodash in es whatever these days though?

our linting rules haven't been updated yet to favor the native implementations, why because fuck everything and everyone

imo this is what happens when you let Perl aficionados design everything

Don't worry, Dan, it will be updated just as soon as Perl6 is production.

Why does every fucking thing have to be a function, how about you () => juggle(myBalls)

juggle(this.nuts)

everything being a function is good not bad tbh