eupolicy.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
This Mastodon server is a friendly and respectful discussion space for people working in areas related to EU policy. When you request to create an account, please tell us something about you.

Server stats:

216
active users

#tdd

1 post1 participant0 posts today

In software development, we have many ways to speed up the time until we get good feedback (in this video, I talk about test-driven development or #TDD).

So, if we are in an environment where we get feedback slowly, we are choosing slow feedback - deliberately or by neglect.

Why are so many choosing slow feedback? videos.devteams.at/w/x5Hkwz6ey

If you prefer youtube, watch here: youtu.be/NIP13D9cEgc

"So you can think really big thoughts and the leverage of having those big thoughts is just suddenly expanded enormously. I had this tweet, whatever, two years ago where I said 90% of my skills just went to zero dollars and 10% of my skills just went up a thousand X.

And this is exactly what I'm talking about. So Having a vision, being able to set milestones towards that vision, keeping track of a design to maintain the levels or control the levels of complexity as you go forward. Those are hugely leveraged skills now.
compared to I know where to put the ampersands and the stars and the brackets in Rust. You know, I'm programming in every language under the sun. And I just kind of don't care. I'm learning by osmosis. I'm learning about the languages. But, you know, and I was a language guy. I loved languages and the details of languages."

newsletter.pragmaticengineer.c

It's fantastic to see TDD gaining traction, especially with LLMs transforming code generation.

The ability of TDD to provide a clear specification and immediate verification for AI-assisted development is amazing. Code quality is up, and feedback loops are tight.

What is Test Driven Development (TDD) and how can it speed up your software development? In this Making Tech Better podcast episode, I spoke to @GeePawHill about why he loves TDD so much and how he has spread that love to software teams all over the world.
You can listen here: youtube.com/watch?v=jJauO_q5dq

www.youtube.com- YouTubeEnjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

The Three Laws of TDD:

1) You may not write production code until you have written a failing unit test.
2) You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
3) You may not write more production code than is sufficient to pass the currently failing test.

— Robert C. Martin

Replied in thread

What you're describing in this thread, @GeePawHill, is micro-testing (famously a clear-box technique, so what you say about it is uncontested), not «canon» TDD (tidyfirst.substack.com/p/canon) as envisioned by those that coined the term TDD.

In #TDD—although also a #clearBoxTechnique—when you write the next test, the box will usually not yet contain the logic to make it pass, so you can't base the test on the implementation of that logic. You run the new test and see it fail to prove that assumption.

Software Design: Tidy First? · Canon TDDBy Kent Beck

I was an #EE undergrad, when I backed into #CS. This was the age when assembly was the JavaScript of the day and structured programming was the state-of-the-fart. So, it was a jolt, when I first encountered Test-Driven Development #TDD in the early 2000s, thanks to the luminaries like Kent Beck, et al. Brilliant stuff!

But, at the risk of being drawn and quartered, I do say that TDD is a bit of a misnomer and an overstatement. Honestly, answer this: do EEs really create the hardware test suits first, before conducting analysis and design, and do CSs really create the software test suits first, before performing analysis and design?

No, we do not! We analyse the problem, we study the requirements, we search for inspiration in the literature, we sip our tea or coffee, we select a candidate solution, we create a plausible design, we implement a prototype, then we test—yes, THEN, WE TEST—if our wild imaginations have any basis in reality at all.

So, I prefer a more down-to-earth descriptionof TDD, which says, "test early, test often, test as much as practicable", not "test first, because".

Hey Mastodon, question for my #sysadmin and #DevOps types. Has anyone used #Pester and #PSScriptAnalyzer to set up unit testing for test driven development, particularly on (relatively) simple scripts like you might use for application detection, installation, and uninstallation from a system like #SCCM #Intune or #ManageEngine ?

Apologies for the buzzword bingo, but I’m trying to reach folks who may be following the hashtags, but not necessarily have a connection otherwise.

It seems like unit testing in Rust is difficult. I am looking into mockall and other mocking libraries, and I'm kind of turned off by all the macros I have to add to my code (and sometimes it even impacts the production code!) instead of being able to keep all test-related stuff in test modules. Also I don't want to use traits for everything—I'd rather not `dyn Trait` everywhere if I don't have to.

How do you effectively unit test in Rust when you have object dependencies?