Discover and read the best of Twitter Threads about #TDD
Most recents (23)
Siguiendo la lógica de #TDD, tus primeros tests en código de producción cuando no tienes experiencia no deberían ser siguiendo TDD
[ H I L O ] ⇩
[ H I L O ] ⇩
La lógica de TDD se basa un ciclo red-green-refactor basado en baby steps o pequeños pasos.
Escribes el test más sencillo
El primer step que falle.
El segundo step que funcione.
El tercer step refactor para optimizar el código
Este ciclo se repite a medida que añadimos tests
Escribes el test más sencillo
El primer step que falle.
El segundo step que funcione.
El tercer step refactor para optimizar el código
Este ciclo se repite a medida que añadimos tests
Esta lógica de ir dando pequeños pasos sigue la tercera ley de hábitos, hazlo fácil.
Es importante para construir un hábito como el de escribir test, empezar haciéndolo fácil porque en base a obtener la recompensa querrás hacer más.
Ya llegará el momento de hacer TDD.
Es importante para construir un hábito como el de escribir test, empezar haciéndolo fácil porque en base a obtener la recompensa querrás hacer más.
Ya llegará el momento de hacer TDD.
¿Escribes código utilizando el sistema 1 de pensamiento o el sistema 2?
¿Sabes que relación tienen con #tdd?
Sigue leyendo ⤵️
#SoftwareDevelopement
¿Sabes que relación tienen con #tdd?
Sigue leyendo ⤵️
#SoftwareDevelopement
Nuestro cerebro es increíble.
Lo que ocurre es que a veces estamos tan convencidos de sus capacidades y sus resultados que pasamos por alto las trampas que nos hace y los errores que nos lleva a cometer.
Conocerlas y comprenderlas es fundamental para tomar mejores decisiones.
Lo que ocurre es que a veces estamos tan convencidos de sus capacidades y sus resultados que pasamos por alto las trampas que nos hace y los errores que nos lleva a cometer.
Conocerlas y comprenderlas es fundamental para tomar mejores decisiones.
El sistema 1 de pensamiento es implícito, es el encargado de dar respuestas rápidas.
Lo hace de manera rápida y frecuente.
Lo hace de manera emocional, estereotipada y hasta subconsciente.
Es útil en tareas automatizadas como andar o pestañear y puede hacerlas a la vez.
Lo hace de manera rápida y frecuente.
Lo hace de manera emocional, estereotipada y hasta subconsciente.
Es útil en tareas automatizadas como andar o pestañear y puede hacerlas a la vez.
Rescatando joyas de youtube mientras dure twitter
String Calculator kata by @ploeh
#tdd #Kata #RIPTwitter #TwitterTakeover #TwitterOFF
String Calculator kata by @ploeh
#tdd #Kata #RIPTwitter #TwitterTakeover #TwitterOFF
String Calculator kata with AutoFixture. Exercise 1
String Calculator kata with AutoFixture. Exercise 2
A function is one of the smallest units of behaviour. Given an input, it returns the output.
This means that given the context (input), the function's behaviour can be verified by calling the function and looking at the outcome (output).
🧵2/22
This means that given the context (input), the function's behaviour can be verified by calling the function and looking at the outcome (output).
🧵2/22
Notice that the most straightforward outcome to verify is the function's return value, but it's not the only outcome we can look for. Functions can have side effects, modify state, interact with collaborators, etc.
🧵3/22
🧵3/22
Why do I practice #tdd you ask?
There’s a number of paths I could’ve taken (or combinations of the four).
1) Write no automated tests.
2) Write tests before writing code.
3) Write tests at the same time as code.
4) Write tests after writing code.
🧵
There’s a number of paths I could’ve taken (or combinations of the four).
1) Write no automated tests.
2) Write tests before writing code.
3) Write tests at the same time as code.
4) Write tests after writing code.
🧵
On a project that’s worth practicing #DDDesign, having no tests is not an option. Continuous refactoring towards deeper insights is the foundation of #DDD and it’s too scary to refactor with no tests.
As a result, refactoring won’t happen without tests and code will rot. Over time our code and our understanding of the domain will either diverge, or we’ll stop looking for insights to avoid change.
TOP 5 TIPS FOR TDD
Last night's video reminded me that there are a lot of good developers out there still making simple mistakes when it comes to #TDD.
Below are my tips for success and why it WILL work for you.
A THREAD 🧵🪡
#SoftwareDevelopment #SoftwareEngineering
Last night's video reminded me that there are a lot of good developers out there still making simple mistakes when it comes to #TDD.
Below are my tips for success and why it WILL work for you.
A THREAD 🧵🪡
#SoftwareDevelopment #SoftwareEngineering
1) Always start with a test.
Writing the test first shapes your design for the better. Starting with a test will set you up to code in an attempt to pass your test, rather than continuously going back to fix code that's tested too late, and failing.
Start as you mean to go on.
Writing the test first shapes your design for the better. Starting with a test will set you up to code in an attempt to pass your test, rather than continuously going back to fix code that's tested too late, and failing.
Start as you mean to go on.
2) New project? It's TDD time.
There's no better time to start using a modern software engineering technique like TDD than when you start new work.
It's a clean slate and a chance for you to make better software and reduce wasted time.
There's no better time to start using a modern software engineering technique like TDD than when you start new work.
It's a clean slate and a chance for you to make better software and reduce wasted time.
0⃣ Clean Code Series: Variables📒🧑💻
It's a guide to producing readable, reusable, and refactorable software in #php #ruby #javascript #python #java, etc. - Software engineering principles, from Robert C. Martin's book "Clean Code"
(code: github.com/jupeter/clean-…)
Thread (9)🧵👇
It's a guide to producing readable, reusable, and refactorable software in #php #ruby #javascript #python #java, etc. - Software engineering principles, from Robert C. Martin's book "Clean Code"
(code: github.com/jupeter/clean-…)
Thread (9)🧵👇
1⃣ Clean Code Series: Variables📒 🧑💻
☑️ Use meaningful and pronounceable variable names
☑️ Use meaningful and pronounceable variable names
2⃣ Clean Code Series: Variables📒 🧑💻
☑️ Use the same vocabulary for the same type of variable
☑️ Use the same vocabulary for the same type of variable
There are a lot of 🔥 takes out there about Test-Driven Development (#TDD)
Let's bust 5 of the most common myths! 🧵 👇
Let's bust 5 of the most common myths! 🧵 👇
Myth 1️⃣: TDD takes too long.
Yes, you will spend a bit more time upfront writing tests versus just writing production code.
However, typing is not the bottleneck for developers. Manually verifying a system works takes way longer.
Yes, you will spend a bit more time upfront writing tests versus just writing production code.
However, typing is not the bottleneck for developers. Manually verifying a system works takes way longer.
Myth 2️⃣: TDD is just about writing tests.
With TDD, tests are the means to the end. TDD is all about writing production code in a different way.
1. Write a small, failing test.
2. Write just enough code to make the test pass.
3. Refactor.
With TDD, tests are the means to the end. TDD is all about writing production code in a different way.
1. Write a small, failing test.
2. Write just enough code to make the test pass.
3. Refactor.
In unit testing, what's a unit? Is it a method? Is it a class? Is it a module? No. Let's clarify this once and for all.
In unit testing, a unit isn't an element of structure. In unit testing, a unit is an individually observable element of BEHAVIOR.
#TDD #BDD #ATDD #UnitTesting
In unit testing, a unit isn't an element of structure. In unit testing, a unit is an individually observable element of BEHAVIOR.
#TDD #BDD #ATDD #UnitTesting
BTW I use @mfeathers explanation that "unit tests are tests that run fast" as a possible valid (foundation/element of a) definition of the term unit test.
Stop arguing which element of structure is meant by unit. Unit does not denote an element of structure. It denotes an element of behavior.
And that shouldn't be surprising: Tests are executable specifications of required BEHAVIOR (NOT: STRUCTURE) by example.
And that shouldn't be surprising: Tests are executable specifications of required BEHAVIOR (NOT: STRUCTURE) by example.
for that first iteration of the code, simple don't mean shortcut:
simple != easy
simple != hacky
simple != rushed
simple != poorly written
even the first cut, MVP, needs to be changeable, testable, clear, expressive, etc
#TDD #technicalDebt #refactoring
simple != easy
simple != hacky
simple != rushed
simple != poorly written
even the first cut, MVP, needs to be changeable, testable, clear, expressive, etc
#TDD #technicalDebt #refactoring
the "make it work" part (K.Beck) always gets mistaken to mean, hack at the code, squeeze, force-fit, finagle, the easiest and quickest thing that'll get the managers, customers, users off our back.
but we just end up on the wrong side of karma
2/3
but we just end up on the wrong side of karma
2/3
it just adds high interest technical debt, and need to refactor out:
- initial understanding, with deeper insight into the feature
- tightly coupled, low cohesion, incoherent, viscous, rigid, fragile, immobile code
#highInterestTechnicalDebt
#technicalDebt
3/3
- initial understanding, with deeper insight into the feature
- tightly coupled, low cohesion, incoherent, viscous, rigid, fragile, immobile code
#highInterestTechnicalDebt
#technicalDebt
3/3
TDD is about design. So with @eventmodeling
it goes out the window. What you have is unit tests to help give you regression tests. But even then, you are doing OCP more than recent years allowed. So plow through the happy path ASAP. Use THAT as the backbone to your system.
it goes out the window. What you have is unit tests to help give you regression tests. But even then, you are doing OCP more than recent years allowed. So plow through the happy path ASAP. Use THAT as the backbone to your system.
More on this at tomorrow's meetup. This is truly agile. I never thought I would ever think to discourage #TDD. But here I am saying exactly that after practising it for 20 years.
So plow through the happy path as fast as possible. Add unit tests later to make sure you covered all the nuances of the data transformations. The regression tests aren't as necessary if you are doing #eventsourcing as you have a bread-crumb trail of how you got into any issues.
#UnitTesting and #TDD continue to deliver
Yesterday, I was fighting a pretty nasty bug, all the unit tests passed
I knew there was a corner case not covered by the unit tests but what was it?
Reviewing my assumptions, the key: hw was not exactly sync
Need to test for data 1/
Yesterday, I was fighting a pretty nasty bug, all the unit tests passed
I knew there was a corner case not covered by the unit tests but what was it?
Reviewing my assumptions, the key: hw was not exactly sync
Need to test for data 1/
Not aligned, I added new unit test for that assumption, of course the test failed
Now, I just needed to modify the code to make that test pass and not make the rest of the tests fail
The best part, i could work with very small and manageable arrays (instead of the 2GB array) 2/
Now, I just needed to modify the code to make that test pass and not make the rest of the tests fail
The best part, i could work with very small and manageable arrays (instead of the 2GB array) 2/
Once all the tests passed, tested with hardware and everything just worked!
Let's see why this worked:
1) there were 35 unit tests that tested the "happy path" and some corner cases
2) I could confidently modify the code and know I would be alerted if I broke existing code
3/
Let's see why this worked:
1) there were 35 unit tests that tested the "happy path" and some corner cases
2) I could confidently modify the code and know I would be alerted if I broke existing code
3/
In my #TDD trainings, I sometimes say that I do not test code that is "too simple to break"; Code where:
1. The chance of the code breaking is very low
2. *If* the code breaks, we would see immediately
What do I mean by that? A thread... 1/
1. The chance of the code breaking is very low
2. *If* the code breaks, we would see immediately
What do I mean by that? A thread... 1/
I wrote the following Typescript code running in #electronjs:
const { dialog, } = remote
const filePath = dialog.showSaveDialogSync({...})
if(filePath) {
fs.writeFileSync(...)
}
The code is very hard to test, but I'm OK with that, b/c it fulfills the above criteria. 2/
const { dialog, } = remote
const filePath = dialog.showSaveDialogSync({...})
if(filePath) {
fs.writeFileSync(...)
}
The code is very hard to test, but I'm OK with that, b/c it fulfills the above criteria. 2/
Before I go into why the code is "too simple to break"... Why is it hard to test?
Well, "dialog" (and even "remote") is not available during unit testing. And even if it was, it would open a dialog that I'd have to remote-control. Not cool in a test. 3/
Well, "dialog" (and even "remote") is not available during unit testing. And even if it was, it would open a dialog that I'd have to remote-control. Not cool in a test. 3/
#DeliveryConf @MrThomasRayner: Messy PowerShell behaviors: A lack of tests, no signed code (not good!), a lack of linting, no peer review (this is a big one!), lack of difference between artifacts in source and prod, no approval, and no dev env.
#DeliveryConf @MrThomasRayner: The same concepts from #CICD that we heard in the keynote earlier are applicable to PowerShell!
#DeliveryConf @MrThomasRayner: A lot of the people doing PowerShell might not have the background in development to provide the basics like storing prod code in source control, having peer reviews to avoid blinders and edge cases, and approval workflows.
تابعت النقاش حول منهجية ال #Agile اللي بدأها الدكتور مازن @mznmel وخلوني ألخص وجهة نظري.
١- الضعف التقني (الشديد أحيانًا) لدى الكثير من فرق البرمجة في السعودية والقفز السريع للادارة هربًا من البرمجة مشكلة كبيرة. شخصيا غير مقتنع بمدير منتج برمجي ما اشتغل برمجة ٥-١٠ سنوات.
١- الضعف التقني (الشديد أحيانًا) لدى الكثير من فرق البرمجة في السعودية والقفز السريع للادارة هربًا من البرمجة مشكلة كبيرة. شخصيا غير مقتنع بمدير منتج برمجي ما اشتغل برمجة ٥-١٠ سنوات.
ما أعرف صراحة كيف شخص يبي يصير مدير منتج برمجي او يصير scrum master وهو لم يعمل قبل كمبرمج. أحد متطلبات التوظيف ك product manager في قوقل مثلا هي ان تكون software engineer بخبرة طويلة.
#TDD, #CodeReview and #ContinuousIntegration in action - here is how with @marcandsweep we develop new features in #JaCoCo (jacoco.org/jacoco/):
as an example let's have a look at github.com/jacoco/jacoco/… …
as an example let's have a look at github.com/jacoco/jacoco/… …
… first we add high level "validation" test to study desired behavior, this test targets Records (openjdk.java.net/jeps/359) that are #JDK14 Preview Feature (openjdk.java.net/jeps/12),
so build fails locally, but only on JDK14 …
so build fails locally, but only on JDK14 …
… yes - locally for development we have many #Java versions installed …
Oh, dang. Now I’m all riled up & can’t focus. Been wanting to go toe-to-toe with <them> in a discussion about #TDD for over a decade. I think I’m going to have to vent. Here. Now.
Ready?
Ready?
First, the history of my introduction to <them>. We met, at a conference, and they said “Ah! You teach TDD? That stuff is dangerous! If Kent Beck were in Europe, he’d be imprisoned for the damage he’s done!”
Let’s generously assume they were using hyperbole, or really angry about something else, or needing therapy. Assume good intentions.
I can answer the questions from my talk at @jaxcon today. There were only two.
@jaxcon "Can you recommend a book on evolutionary design?"
I can recommend a few. You can probably feel comfortable starting with any of them.
- Beck, _Test-Driven Development: By Example_
- Koskela, _Test-Driven_
- Jeffries, _Extreme Programming Adventures in C#_
I can recommend a few. You can probably feel comfortable starting with any of them.
- Beck, _Test-Driven Development: By Example_
- Koskela, _Test-Driven_
- Jeffries, _Extreme Programming Adventures in C#_
Nessa mini-thread, vamos explorar conceitos sobre Testes Unitários e #TDD. Vem comigo! 👇
Testes Unitários, de Integração e End-to-End são tipos de testes automatizados que compõem o núcleo do Continuous Delivery, uma metodologia de desenvolvimento que permite que você suba implementações para produção em dias ou horas, ao invés de meses ou anos.
Cada tipo de teste possui um papel único e isolado. A partir de agora, iremos começar a explorar conceitos de Testes Unitários com TDD.
All of you #recruiting #fullstack developers, or calling yourselves #fullstack #software #developers, this is the stack. I call #shenanigans.
#UI & #UX
#Accessibility
#Internationalization
#GraphicDesign
#Javascript
WAF and client-side #security
Client-facing #performancetesting
Caching & #CDN
#APIDesign
Identity management
#Microservices
#Database access patterns
#ContinuousIntegration
Build servers (#Jenkins)
#Accessibility
#Internationalization
#GraphicDesign
#Javascript
WAF and client-side #security
Client-facing #performancetesting
Caching & #CDN
#APIDesign
Identity management
#Microservices
#Database access patterns
#ContinuousIntegration
Build servers (#Jenkins)
Source code management
Deployment methodologies
#ConfigurationManagement
#InfrastructureAsCode
Infrastructure Security
#TDD
Concurrent programming
Backend performance testing
#Monitoring
Alerting
Storage subsystems
Messaging subsytems
#Networking
Deployment methodologies
#ConfigurationManagement
#InfrastructureAsCode
Infrastructure Security
#TDD
Concurrent programming
Backend performance testing
#Monitoring
Alerting
Storage subsystems
Messaging subsytems
#Networking
Getting started with Want to succeed with #TDD ? Stop writing tests! @BurkHufnagel #TDD #DevNexus devnexus.com/presentations/…
We work with software that's way more complex than a simple shape like this. Reasonable people may see the same thing in different ways, based on their perspective! @BurkHufnagel #TDD #DevNexus
You have a goal that you share with me: you want delivering better code faster
... not *writing* code more quickly! @BurkHufnagel #TDD #DevNexus
... not *writing* code more quickly! @BurkHufnagel #TDD #DevNexus
Bir yazılım geliştiricinin bilmesi gerekenlerle ilgili 15 maddelik flood geliyor.. Mümkün olduğunca fazla keywordü bir araya toplamaya çalıştım.
Hadi Başlıyoruz!
#Developer #Software #Java #code #kod #yazılım #development #computer #bilgisayar #tool #PC #IT #web #tech #data
Hadi Başlıyoruz!
#Developer #Software #Java #code #kod #yazılım #development #computer #bilgisayar #tool #PC #IT #web #tech #data
1-Temel veri yapıları (linkedList, map, tree vb) ve temel algoritmalar (sıralama, arama vb)
Sıfırdan kodlama ihtiyacınız büyük ihtimalle hiç olmayacak. Ancak ihtiyaç anında doğru yerde doğrusunu seçebilmek için o veri yapısının veya algoritmanın nasıl çalıştığını bilmeniz şart
Sıfırdan kodlama ihtiyacınız büyük ihtimalle hiç olmayacak. Ancak ihtiyaç anında doğru yerde doğrusunu seçebilmek için o veri yapısının veya algoritmanın nasıl çalıştığını bilmeniz şart
Some days I'm really frustrated by people holding opinions in the face of experiments and data showing the opposite. It's one thing to say that the experiment isn't valid (and then please say why you think so), it's another to misread it entirely.
I'll be the first to admit that experiments around things like TDD are hard, but Medium posts like this one don't even attempt to look at the literature. blog.usejournal.com/lean-testing-o…
To inject some data into the discussion, sciencedirect.com/science/articl… is a good survey on the research on #TDD through 2014.
