New/nuevo post:
"Isolated" test means something very different to different people!
https://codesai.com/posts/2025/06/isolated-test-something-different-to-different-people
#legacy_code #SoftwareEngineering #CodeQuality #Tech
#tdd #cleancode
Subscribe to our newsletter: https://codesai.com/newsletter/
[Non mixte] un kata sans FizzBuzz, c'est promis
16 juin 2025, 19:00:00 CEST - GMT+2https://mobilizon.fr/events/1aca552e-f3c6-49b7-a388-3440365830e3
European Spreadsheet Risk Annual Conference Programme announced
Thursday 3rd and Friday 4th July 2025
University of Greenwich, London, UK
https://eusprig.org/conferences/eusprig-annual-conference/
Spreadsheet Entertainment
AI and LLMs
Excel languages
Research into human-computer interaction
Horror Stories
Register on https://eusprig2025.eventbrite.co.uk/
@EuSpRIG #eusprig #conference #London #HCI #research #AI #LLMs #Excel #TDD #Spreadsheet #Risk
@jasongorman yeah, I mean what's with the extraneous checking of x and y and the exception, just return 9 and be done. 
I've definitely been in that workshop. #tdd
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: https://www.youtube.com/watch?v=jJauO_q5dq8
It was a successful weekend for #Komunumo, the new federated meetup alternative: Now there is a header on every page, and on the homepage the communities are displayed with their picture in a responsive grid. Architecture tests with #ArchUnit were introduced and thanks to #TDD we have a test coverage of 100%. This gives us a good feeling for refactorings and also when testing PRs. I'm already looking forward to spending a few evenings working on it next week! Screenshots will follow soon! 
I find myself in strong agreement with John Ousterhout about #TDD: it encourages an approach to software development that is more tactical than strategic and typically takes a toll on design. Like Ousterhout, I tend to resort to TDD only when I'm fixing a bug.
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
Who would have thought that 250 would have already listened to A Junior, A Senior and I 
https://open.spotify.com/show/7AMbqJv7HCdSDiTG1nvUaa?si=WULciwKFTx-DMXSm6iYlwQ
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 (https://tidyfirst.substack.com/p/canon-tdd) 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.
One danger of a too transparent box used for TDD is that tests get too coupled to a specific implementation and thus hinder refactoring and evolution. ie, taking the soft out of software.
Sure you are aware of that, but novices easily fall into that trap, when they not have learned enough about refactoring towards simpler code.
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".
Ever wondered how beforeEach works in unit test frameworks? Check out our new lifecycle diagram!
https://qunitjs.com/lifecycle/
People generally guess right when it comes to ordering, so why a diagram?
We want to show that the order is guaranteed, and showcase what's possible when you depend on it.
Thanks to FND, Jan, and NullVoxPopuli for improving and promoting this work! H/T @FND @simulo @nullvoxpopuli
Ship Software That Does Nothing
https://kerrick.blog/articles/2025/ship-software-that-does-nothing/
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.
#Java Live Coding Stream
In an hour (6pm UTC) I'll be continuing work on the event-sourcing aspect of JitterTed's TDD Game online (https://tdd.cards).
Join me on Twitch for Java, #EventSourcing, #TDD, #Refactoring, mistakes, rants, and more: https://jitterted.stream
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?
BLOGPOST: A pleasant diversion with #TDD
I was recently nerd-sniped (in a good way) by a blogpost from @RonJeffries so I tried my hand at the problem myself and wrote up as I went.
As a bonus, almost all of the blogpost (minus some minor typo corrections and code samples) is generated directly from the commit history!
https://blog.probablyfine.co.uk/2025/03/16/a-pleasant-diversion-with-tdd.html
