36. > Stay Connected.
Tiffany Larson
linkedin.com/in/tslarson
9/24: Cloud-Native Data Architecture: Break Away From Data Monoliths for Cloud-Native Applications
9/25: Building Data Environments for Production Microservices with Geode
#springon
e
@s1
p
Editor's Notes
Thrilled to be at SpringOne
Excited to share something I’ve been learning about
XP best practice - (
It’s not about writing one giant test that contains all of the logic necessary to complete your feature or bug.
TDD is an iterative, discovery driven process.
By walking through incrementally the idea is you’re hopefully able to drive out and test edge cases.
It’s Challenging - Different way of thinking
Don’t know how - Most bootcamps/schools don’t emphasize…
Usually not a requirement of the entire curriculum
So it’s not a habit…
They don’t know how…
If it’s because they don’t want to - that’s a little outside the scope of this talk.
But an important conversation to have
Break this up into 3 topics
Brief amount of time on the habit cycle and how to intercept routines that are not conducive to TDD
This order matters -
If you’re trying to teach someone but you aren’t spending a moment to figure out how to speak their language, you’re doing a dis-service to both of you.
Agile Manifesto - Focus on the person first and then the process
Once I get those things - I’m going to apply that knowledge by incrementally teaching them a new concept
Focus on the big three
Most people are more than one
Majority of people know what type they are
* "I can't picture it..."
* Always remember a face
* Take lots of notes (prefer to see words written down)
* Might not be great at remembering or following verbal instructions
Usually ask me a question more than once
Once I find out they are a visual learner - I encourage them to take notes and try to give them the time while we are pairing to write things down
Post it notes for (shortcuts) syntax
* Talkative / story tellers
* Remember lyrics to songs/movie quotes
* Good listeners
* Prefer discussions over reading articles
They are the hardest for me to teach
Let your pair drive out if they need visual stimuli
They learn really well by explaining things to others
Learning is done by carrying out physical activities
Very hands on
Enjoy making and creating
Fidget a lot
Eat snacks while studying
Talk with their hands
Letting them fail
Need to do something active while learning
We’re going to revisit these strategies later when get into achieveing milestones,
the key to TDD is Test Driven or writing the test first.
It’s not enough to just know how to write tests.
What happens is dev starts a feature, takes a minute to figure out what they want to do, and then starts writing the code. (Comment it out). What’s happening here?
To get to writing tests first we need to understand the habit cycle….
Power of Habit by Charles Duhigg
Alcohol. Cracking knuckles.
Is the cue - I don’t know what to do so I need to try some things?
I know what to do and I want to create business value ASAP?
I don’t know how to write a test for this?
No secret - spend some time with your pair understanding their habit cycle.
how hard/discouraging it is to try and get someone to understand TDD in a day.
Can’t TDD if you don’t know how to write a test
If we did that, it would be a big win.
…(Next slide) Can we find smaller wins along the way to celebrate?
Scary code slide next…
This is end goal…
Dog API for dogs without names.
Takes in dog data (like their color and fears), calls a client to get a name, saves the dog.
This test is calling our createDog method, and verifying client was called and it was saved
This test is calling our createDog method, and verifying client was called and it was saved
How can we break this down into smaller learning modules?
(Looking at that last slide - you can break the learning down in 3 modules)
3 modules
Reason I like to start with verify - don’t know final implementation
Consistency helps not start from scratch every time they open a test
Have conversations about the setup (something I did wrong)
(More complicated) What are we testing and what do we mock?
What to say to visual learners/auditory (might start a convo re dep. injection)
Memorization
When do you use it?
How do you use it?
What does the error mean? (Or, what does a successful failing test look like)
Write down the name of the test for them. Understanding how to incrementally break down a problem and how to write a test are different milestones.
When do you use it?
Auditory learner - let’s talk through how we are going to write this test
How do I use it (syntax)
What’s the error?
When do you use it?
How do you use it?
What does the error mean? (Or, what does a successful failing test look like)
Stop for your auditory learners
Understand how your pair learn and how you learn
Create consistency in your visual setup (how you name things), the descriptive language you use, and the way you build your tests.
Treat teaching like TDD
(Treat teaching like TDD)
TDD is an iterative, discovery driven process.
Find your failing tests! Asking those questions…
Use strategies that make sense to your pair to get those tests passing.
Focus on the person first and use that knowledge to help get them through the process.