Robert C. Martin introduces the principles and practices of Test-Driven Development to write robust and maintainable code.
↓↓ ENGLISH DESCRIPTION ↓↓
"Coding Better World Together" is a set of master lessons from the famous Uncle Bob (Robert Cecil Martin), where he gives us a broad vision of the importance and future of Software in today's society.
In this fourth lesson, Uncle Bob introduces us to a software development methodology oriented through testing. This is the Test-Driven Development (TDD), a practice with a long learning curve, but with significant results to generate a more robust, safer, more maintainable code and with greater development efficiency.
Among other things, Uncle Bob shows us his point of view about the evolution of software to this day and its bright future.
↓↓ DESCRIPCION EN ESPAÑOL ↓↓
"Coding Better World Together" es un conjunto de lecciones magistrales del famoso tío Bob (Robert Cecil Martin), donde nos brinda una visión amplia de la importancia y el futuro del software en la sociedad actual.
En esta cuarta lección, el tío Bob nos introduce en una metodología de desarrollo de software orientada a través de pruebas. Se trata de el Test-Driven Development (TDD), una práctica con una curva de aprendizaje prolongada, pero con resultados significativos para generar un código más robusto, más seguro, más mantenible y con una mayor eficacia en el desarrollo.
Entre otras cosas el tío Bob nos muestra su punto de vista acerca de la evolución del software hasta nuestros días y de su brillante futuro.
Opening.
Honest Estimates / What is the chemical formula of water?
Selection, Secuence and Interaction / No innovations have been made in the software for decades.
The Hardware has gone crazy!: comparison between the innovation level of hardware and software today.
You to say "No".
Test-Driven Development / TDD rules.
Our code is a document / Double entry Bookkeeping.
About inheritance / Mutation Testing.
Demo of Test-Driven Development.
Some tips to learn and practice Test-Driven Development.
Questions and Answers.
↓↓ OUR MODEL OF SOCIETY ↓↓
- mutualwelfare.org
↓↓ NUESTRO MODELO DE SOCIEDAD ↓↓
- bienestarmutuo.org
↓↓ OUR CRIPTOCURRENCY FOR MONETARY FREEDOM - NUESTRA CRIPTOMONEDA PARA LA LIBERTAD MONETARIA ↓↓
- unitycoin.net
- PRESENTATION: unitycoin.net/presentation/
↓↓ OUR PAYMENT FRANCHISE - NUESTRA FRANQUICIA DE PAGOS ↓↓
- sbmlibre.com
↓↓ OUR SOCIAL PACT - NUESTRO PACTO SOCIAL ↓↓
- e-nation.org
- PRESENTATION: e-nation.org/presentation/
↓↓ OUR SOCIAL NETWORKS - NUESTRAS REDES SOCIALES↓↓
- Facebook: es-la.facebook.com/unitycoin/
- Twitter: twitter.com/unity_coin
Why it's here
3 people recommend this
What people say. Recommended as an excellent introduction to the value and practice of Test-Driven Development.
Moments people linked to
A
u/Accomplished_Deer_in r/programming • Recommends
On “The only way to go fast, is to go well (TDD from Factorio)”
Uncle Bob addresses this: [video
What if you instead used the tests to guide the explorative coding? The thing that only snapped in my brain a few days ago is this: If I'm manually testing, I'm just wasting time doing something manually that I'm going to have to automate very soon anyway.
Taking the time to write the test first makes it so I don't have to manually test, and it also guides the code that I'm writing. If I'm writing explorative code without tests, it's possible that my exploration isn't even solving the thing I'm trying to make it solve. And if it is, and the way I know this is manual testing, then I might as well have written the test anyway.
Assuming you are doing…
link to this video (skip 21 mins in)
Is a pretty interesting talk and demo about TDD given by Uncle Bob, which you may find interesting.
I always kind of hated unit tests and wrote them because "I should". Since this I've grown to love trying to adhere to the TDD rules as strictly as possible (even in JavaScript).
This whole series of talks is amazing btw and I can't recommend them highly enough.
On “The only way to go fast, is to go well (TDD from Factorio)”
I'd recommend watching at least a few minutes of this Uncle Bob video, note the timestamp. [video
(FYI, I'm basically talking out of my ass here. I have always struggled with writing tests, after recently doing a bunch of reading and watching a bunch of Uncle Bob I think I finally see the value of TDD, but I haven't been working on anything lately so I haven't had a chance to try it.)
TDD isn't about being 100% correct or figuring out every single edge case, it's about writing testable code. If you write tests before code, it's going to be very difficult to write un-testable code. If you write code first you'll often go back and write crazy complex tests because that's the only way to…
On “Why Haskell is our first choice for building production software systems”
As a TDD fanboy, I did learn from this talk that null checks and "for all x in X"-like constraints are better expressed using type systems. I will definitely look into that. But there are some things I didn't understand about your experience with TDD. I hope I don't put you off with my questions.
# Question 1
You mentioned painting yourself into an architectural corner, and that you had a hard time implementing User Story 4 of the Kata. This happens all the time for me as well. Reminds me of the How to draw an owl meme.
use case 4
| | | | | | | | |
| | | | | | | | |
=> 711111111
My question here is, *did you try to create your own stepping-st…
