View profile

Test-driven development (no, really)


Radial Development Group

August 10 · Issue #28 · View online

Our thoughts on running a company, tech insight, news, and nerd life.

Hi Friends,
Engineers learn about test-driven development in college classes or bootcamps. One of our developers recently told me he learned TDD was a “best practice, but no one actually does it.”
Basically, he learned it was a good thing to talk about in a job interview. Outside of that, it probably wouldn’t be something he had to do. 
Before we dive into why this is, let’s have a brief definition of TDD. Generally, it means is you write tests before you write code. 
Your test says something like: “I expect a user to be able to log in using Google.”
At first it fails, because the application only lets people log in with their own username and password. Then, you write the code to allow users to log in with Google. All of a sudden, your test passes. Tada! That’s TDD. 
The beauty of TDD is that it focuses your work. You know exactly how you want the code to perform, and then you get it to do that thing. 
Test-driven development also ensures that if someone unwittingly removes a line of code and breaks the Google login, the test fails. Everyone knows immediately what went awry.
Testing this way helps maintain consistency. It also prevents anyone from introducing new bugs that break existing functionality. 
Our new hire was surprised that we actually practice TDD at Radial. Even though it has all these advantages, it is often overlooked. 
Often, non-technical project managers see TDD as a time sink. It does take time. It also means businesses and developers have to prioritize what is important to test, and what isn’t worth it.
As any engineer who has pulled an all-nighter hunting a regression bug will attest: TDD saves time in the long run. But many engineering cultures focus primarily on short-term results and discount these longer term costs.
Whether it is 3 months or 3 years later, a lack of quality testing will drag your project down eventually. The question is, do you want to pay the cost incrementally up front, or in large chunks later on? It’s worth thinking about.

If you eat Nutella, you might be doing it wrong.
School lunches still look a lot like they always have.
Being Better
Journaling prompts from our friendly neighborhood nerd, Ariana F. at Rosabella Consulting.
What if, “as soon as you notice yourself suffering you automatically embrace yourself with compassion?” That’s a quote by Kristin Neff that lives on the home screen of my phone.
When we effectively rewrite limiting patterns into empowering practices, we open up new possibilities for ourselves. Limiting patterns are draining. Rewriting takes time and consistent effort.
The fourth step in Rewriting Limiting Patterns is Redirection. This happens when we’ve effectively re-patterned our trigger reaction loop – creating a new and empowering habit to a persistent stimuli. While it is hard work, the reward is well worth it.
Here are some journaling prompts to help you move into the fourth (and final) step in the Pattern Rewrite Process:
  • Which pattern interrupt(s) worked well for you?
  • Repetition, repetition, repetition - How and when will you practice using this pattern interrupt?
  • What can you do to prime yourself in advance of a triggering situation so you are equipped to redirect into a new positive response?
Are you tired of feeling like others are taking advantage of you? Have you struggled to draw and maintain boundaries?
Check out our next Journal Jam and gain insight to courageously and gracefully draw boundaries with just 20 minutes of journaling. Details and registration are available online here.
**Want to try the August Journal Jam for free? Use the code RadialRocks when checking out!**
Did you enjoy this issue?
In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Loveland, Colorado