loading words...

Nov 30, 2018 21:04:55

Unit Testing for Minimal Viable Products

by @mattlo | 343 words | 🐣 | 7💌

Matt Lo

Current day streak: 0🐣
Total posts: 7💌
Total words: 3218 (12 pages 📄)

I'm a software engineer by trade and so I try to follow the best practices every time I need to work on some code. One thing that bothers me is when should I write unit tests for code that may change later on?

What if the feature is a beta user interface? What if you've manually tested it and it works fine? How do you justify to your customers that you've checked everything but haven't written automated tests for it?

I've come to answer these in the most pragmatic way possible: through the order of importance. As a founder, I need to worry about other issues too, like user feedback, product-market fit, scalability, marketing, sales, etc... There's no way I can spend time writing tests all day when there's money to make.

What I've learned to do is write unit tests for critical path functionality only. Signup, onboarding, end-user product functionality. Things that matter to the business immediately.

I'm not going to write `setUser(mockUser); assert(instance.user).toBe(mockUser);` and I'm not going to endlessly make Jest snapshots for every React component. What I will write is a mixture of end-to-end testing and unit testing — ones where resiliency matters.

For example: insertion of a credit card and a mock call to Stripe. If that doesn't work, I'm not making money.

Another example: Unit test on headless browsers that ChipBot (my startup) can open in a wide array of browser environments.

For customers who question tests? You answer that you test everything. You most likely already manually test all your products. Adding the critical path unit tests only strengthens your foundation.

Finally, often times you will be throwing away your own unit tests for new features. I've refactored 3 or 4 times for my MVP and I've avoided premature unit tests. Writing quality tests will become a priority when your product matures.

In the beginning, there's no time to rigorously follow TDD or to hit 80% coverage. You have to test based on what matters most in the beginning. 

Your MVP requires getting user feedback ASAP.

  • 1

    @mattlo this couldn't be more true! Usually I save time by creating data fixtures with basic unit tests (create/update/delete functions) within. I never do functional testing until much later, for obvious reasons.

    Basile Samel avatar Basile Samel | Dec 01, 2018 06:28:17
    • 1

      @basilesamel love this insight, I wish more people would be open on how they test

      Matt Lo avatar Matt Lo | Dec 02, 2018 09:16:49
  • 1

    @mattlo Yeah, for side project testing too early is a waste of time. No point spending time writing test when you could write new features if you're in the early stages. Later on having tests is going to save you lot of time and headache trying to figure out what works and what doesn't.

    Valentino Urbano avatar Valentino Urbano | Nov 30, 2018 21:14:30
    • 1

      @valentino Totally agree. The other part of this is managing the critics. The people who don't work in startups but advocate unit testing like day and night. There's a battle on every front!

      Matt Lo avatar Matt Lo | Nov 30, 2018 21:36:51
contact: email - twitter / Terms / Privacy