Tying up loose ends at the end of the day feels nice. Completing a task, committing my work, and shutting my laptop leaves me with a satisfying sense of accomplishment that sticks with me through the evening. And on those days when I grapple with a problem for a while and don’t come to any resolution, I can feel a little defeated.
While it’s nice to watch my test suite pass and call it a day, I’ve found that some of my most productive mornings come when I’ve left myself a failing test the night before.
Mornings are a great time to get caught up and plan. But it can be challenging to transition from organizing and digesting to opening a text editor and getting into a flow state. When I get some momentum working on a tricky problem later in the day, I want to bottle it up for morning. I can get close with one failing test.
Starting with a failing test means I know exactly what to work on: making it pass. Compared to an item on a to-do list, a failing test is better at returning my mind to the state it was in when I was focused deeply on the task. Maybe I even spent a bit of time the night before thinking about how I might approach it, so the implementation is a quick win.
It doesn’t work all the time. Sometimes, priorities change overnight, and I have to put the test aside and focus on something else. But often, I find that a little time spent writing a failing test at the end of the day lays the foundation for a great morning.
Top comments (25)
I often struggle with a piece of code in the day and then first thing in the morning am able to solve it easily.
Great idea. Reminds me of something Earnest Hemingway said:
So it seems you're in good company!
Thanks, Chris! Love that quote. It's hard to stop when things are going good but it can be great for maintaining momentum.
Or when it's starting to go bad but you know it'll be fine when you revisit it with fresh eyes. The worst time is 1am when things seem hopeless.
Writing notes to yourself through tests, great idea!
Thanks! That's the idea. When I leave myself notes in the form of tests instead of prose, I'm less likely to come back to them the next day and wonder what I was thinking. (Although I've written some pretty confusing tests, too 😉 )
Should I try ending today with a failed production deployment for a great day tomorrow? :)
That would certainly help to focus your attention on one thing to start the day! Why don't you give it a shot and let us know how it works out? 😉
I will keep you in the loop
That's an interesting idea, Nick. Maybe I'll try it myself..
How do you keep yourself from trying to make the test pass at night?
Trying to solve it and leave no loose ends is very tempting...
And also, do you use TDD or BDD?
Thanks!
It can definitely be tempting to tie up all loose ends at the end of the day. I've found that shutting down my laptop and cleaning up my workspace right after I've written the failing test can help me move on.
I do use TDD pretty regularly, and this idea has fit well within the red-green-refactor cycle for me.
I'll try that :)
Which languages do you work with? do you use any unit testing/mocking frameworks?
I work mostly with Ruby and JavaScript. I use RSpec for most of my Ruby testing, including unit tests. I haven't done much unit testing in JavaScript, but I'll test interactions with JavaScript in the browser using Capybara and ChromeDriver.
Sounds interesting :)
Any suggestions for mocking frameworks for the server side?
I generally try to avoid mocking whenever possible.
When I'm testing requests to external services in Ruby, I'll use VCR and WebMock so that my test suite doesn't need to make HTTP requests, and when I'm testing how an application handles webhook events, I'll write fixtures to fake the payloads of incoming requests. Very occasionally I'll reach for the mocking built into RSpec for other purposes.
But for the most part, I tend to avoid mocking.
Why do you tend to avoid mocking?
When it's feasible, testing the real system rather than mocks gives me more confidence that the thing I'm testing actually works.
I understand what you mean, but mocks can help you test more cases, thus you can be confident that the thing you're testing works on edge cases too, don't you think?
Yes, I do this sometimes. It's a good reminder about what you were working on. I often also stick invalid code into the source, so my compiler helps remind me where I was. Such as
!!!!!!!!!!!! argh, xVal isn't right hereThat's a really great idea! Usually I love the closure of having all my tests passing once I'm done for the day... but I'll often have to remind myself what I want to do next, which is hard when you just start off the day and have no momentum yet.
It's indeed a way to make sure you can start tomorrow on a roll, but what if you have a policy that demands a building solution every time you commit? For continuous delivery, such a thing is very important. You could let a failing test only be a warning upon build, but the question is whether that is a good idea.
I don't commit until I've made the test pass. That means I'm leaving unstaged changes on my laptop many nights. If you're not comfortable with that, you could also try stashing your changes, or committing your changes and amending the commit before pushing it.
I like this concept of ending things and starting new ones in the middle of the day.
It gives you that boost early in the morning to finish up what's left.
I can relate