schmonz.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
Video 4 of #TDD with #SwiftUI: Did you know that Xcode behaviors can help change _your_ behaviors as a developer? https://www.youtube.com/watch?v=uEpBDR_f3tc
#TDD with #SwiftUI — Jon Reid livestream
🗓️ Sunday, June 29, 9:30am Pacific, 16:30 UTC
Join longtime iOS unit testing instructor, Jon Reid ( @qcoding ), author of “iOS Unit Testing by Example”.
https://www.twitch.tv/qcoding
3/4
"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."
https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent
#Programming #AI #GenerativeAI #VibeCoding #XP #TDD #SoftwareDevelopment #SoftwareEngineering #TestDrivenDevelopment
@jlink that's because "developer productivity" is hard to define and even harder to measure. All in all my key metric is shortening the feedback cycle(s). #TDD does a great deal in that. But you also have to do (real) continuous delivery. Even #AI can help with that (cycle time) when it comes to rapid prototyping and quickly explore an idea or technology.
A classroom of open-minded people, eagerly learning and practicing "Refactoring Legacy Code Guided By Approval Tests" at @amsterdam 2025. Thanks to all participants for joining and sharing your unique perspectives. Also a big thank you for all the great feedback.
#refactoring #legacycode #tdd #approvaltests #softwaredesign
If you really really want to increase your developers productivity, teach them proper #TDD and give them time to refactor.
I'm speaking at this year's #Devopsdays Amsterdam, happening next week June 18-20. I'll be hosting my workshop "Refactoring Legacy Code Guided By Approval Tests". So come join this fun event with me, and network with like minded people about #DevOps and more. And to make things even better, use the voucher #FRIENDS_OF_SPEAKERS when buying your ticket for a 20% discount on the regular 2-day ticket.
https://devopsdays.org/events/2025-amsterdam/welcome/
Hope to see you there.
so good I wrote #playwright tests yesterday, I knew the complexity was beyond me comprehending the validity of the code.
That's when I start applying tests and #TDD lately.
Why do I start testing so late?
Well I passed the line of the code being for throw away, since I am coming back and actively being interested in it keeping to work.
curious to see the tests? https://codeberg.org/wolframkriesing/spaish/src/branch/main/tests/details.spec.js
for this project: https://picossg.dev/tools/spaish/
#OpenToWork Hi y'all.
I'm now properly looking for a new job, available from early September for a senior software role. Ideally, in #Kotlin or Java-to-Kotlin conversion. I think I can tick just about all the important boxes for backend development and some more. (especially XP, #DevOps, #TDD, trunk-based development, pairing, fast feedback cycles). Ideally, #remote or flexible #HybridWorking in #London (the one in the #UK).
Would it be possible to transfer the test-driven development paradigm over to writing fiction? Test-driven novel writing? I think so!
Here’s my pecha kucha talk on the topic from @Oop Munich: https://youtu.be/s9rPI1lPWfc
Leanpub book LAUNCH 🚀 The Software Developers’ Guidebook: A Collection of Modern Engineering Practices by Dave Farley https://youtu.be/C0OL14tVx2c #books #ebooks #newreleases #booklaunch #programming #softwareengineering #DevOps #Agile #Lean #softwaretesting #TDD
Don't miss out on the technical content at Agile 2025!
Join me in Denver in for my talk, “Test-Driven Development: Exploring the Spaces in Between”. I'll expose the hidden thinking behind the actions.
Get tickets: https://agilealliance.org/agile2025/
#Agile2025 @AgileAlliance
Leanpub book LAUNCH 🚀 The Software Developers’ Guidebook: A Collection of Modern Engineering Practices by Dave Farley https://youtu.be/C0OL14tVx2c #books #ebooks #newreleases #booklaunch #programming #softwareengineering #DevOps #Agile #Lean #softwaretesting #TDD
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
Leanpub book LAUNCH 🚀 The Software Developers’ Guidebook: A Collection of Modern Engineering Practices by Dave Farley https://youtu.be/C0OL14tVx2c #books #ebooks #newreleases #booklaunch #programming #softwareengineering #DevOps #Agile #Lean #softwaretesting #TDD
My live-coding #TDD with #SwiftUI will be back next Sunday. Follow me at twitch.tv/qcoding to get the go-live notification.
The last session was so good, I spent time adding chapter timestamps. If you can't join live, subscribe to my YouTube channel for my next video. https://www.youtube.com/watch?v=pAd8AEJIVyw
For me this approach of writing tests after the production code add too much overhead to the development process. I like to prevent such unnecessary headaches. That's why I find Test-Driven Development to be the most effective approach to developing software.
Test-Driven Development can be considered as reducing your WIP (Work-In-Progress) at a microlevel. By focusing on writing just enough code to make a failing test pass, refactoring what you added and push to source control, we minimise the amount of unexecuted code (= WIP). Limiting WIP is essential for fast software delivery.
I find that the issue Kent Beck talks about here:
https://tidyfirst.substack.com/p/why-tdd-doesnt-lead-to-dumb-code
... is very fundamental to TDD and centers around a couple of commonly missed aspects of it (even though they are spelled out in Test Driven Development by Example)
1- When passing the test, there is a Fake It approach you can take if you don't see the Obvious Implementation right away before you move on to Triangulation and add more tests.
2- When you are using Fake It, the Refactoring step is not primarily about making the code "nicer", but generalizing by removing the duplication between the test and the production code. This is only refactoring in the sense that you are staying green. That's why the step is not optional and getting to green using the simplest, naive implementation is a core part of the process.
I think not using Fake It is one of the two main reasons people fail with TDD (the other is not making writing more testable code a design goal.)
_Event-Sourcing Live Coding_
I've been live coding an example #EventSourcing app in #Java (via #TDD) w/o an ES library.
This week I'll continue to code the "Time-Traveling Event Viewer" to view the state at any point in time.
Join me Mon-Thur 18:00 UTC https://jitterted.stream
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.
LIVE CODING STREAM THIS WEEK
After an awesome time at #ExploreDDD, I'm back home and ready to continue working on JitterTix, the example #EventSourcing app in #Java, #TDD, a tiny bit of #SpringBoot and no other libraries (well, a few small ones, but not for the EventSourcing).
> Test-driven development (TDD) is a way of writing code that involves writing an automated unit-level test case that fails, then writing just enough code to make the test pass
(Wikipedia)
So, #TDD fans, how do you write your first test(s)? Like, how do you deal with the fact that none of the implementation you will be writing has any names yet? Do you violate this principle some and stub out implementation objects to give them names? Do you write tests that "fail" due to missing names? In a statically-typed language, how do you accomplish the later -- consider failure to compile a "test failure"?
I'm generally a fan of TDD, but I never _actually_ start from the tests. They are always something that comes later but, potentially, become a driver in the future.
AceUnit v3.0.0 is officially released!
Enjoy a new world of unit testing C with automatic test discovery!
#PairProgramming (if you'd like to) #TDD #JUnit5 #Kotlin #Java
_Event-Sourcing Example App_
Join me in 1 hour (18:00 UTC) as I continue work on JitterTix, an example app demonstrating how to do #EventSourcing in #Java (and #SpringBoot) without ES libraries, but with #TDD.
Source code is at https://github.com/jitterted/jitterticket-event-sourced
_JitterTix Concert Ticketing System_
On my #Java live coding stream this week I've been working on a simple concert event ticketing system that is based on #EventSourcing. I have several reasons I've been doing this (putting my #TDD Game on hold).