DEV Community

Cover image for Test Driven Development - not Unit Test Driven Development

Test Driven Development - not Unit Test Driven Development

Vlad Dubrovskis on January 25, 2020

A lot of us in software development would have heard of Test Driven Development. Some swear by it - some hate it and say it is fully unnecessary. ...
Read full post
 
vladdubrovskis profile image
Vlad Dubrovskis •

I have a hypothetical question:

Let’s say you work on a micro service/lambda. You start with TDD and slowly work your way up to higher level tests and application.

As you navigate higher do you end up with all the unit tests you have written throughout or at some point some become obsolete due to integration tests?

My example I have written previously is:

  1. let’s say an endpoint needs to fetch data from other service
  2. I write a test and function that will make http request and give data back
  3. I write test for endpoint that modifies that data from that function above
  4. I write implementation

Depending on how I write the test in step 3, I either mock function from step 1, or HTTP layer again same as in unit test for data function. With latter the unit tests feel like it is obsolete. Yes you probably are losing more granular feedback but then test is better? Plus if I change the function/module in step 1 but data remains same - I don’t have to change tests anymore.

I am still trying to narrow down my exact hypothesis 😀

 
vladdubrovskis profile image
Vlad Dubrovskis •

Thanks for your thorough replies Andy - appreciate your time and wisdom :)

I think the last paragraph captures what bothers me the most - when the tests start taking up more time than they should (wonder if there is a measure/metric? everything is 80/20?
😂)

I will think about it a little longer and may come back to this conversation in the future 🙂

Collapse
 
aleksikauppila profile image
Aleksi Kauppila •

but higher level tests tend to cover a much broader scope of functionality, so switching from red->green is probably going to require a much larger amount of implementation, which will hurt the speed of your feedback.

This is so important. Well put. 🙏

Collapse
 
vladdubrovskis profile image
Vlad Dubrovskis •

Fair points and fully agree with idea that when starting with something that I know will be quite a big piece of software with a lot of concerns - will opt in for unit level tests to help design separation of concerns and slowly build up the design or blueprint of my solution.

I think will need to come up with a series of examples and try writing different tests to see what works best in certain scenarios.

My main example for integration/e2e tests is Lambda because it usually should be small enough that having unit, integration and e2e tests seems like an overkill.

And often see a lot of tests in a codebase where behaviour is... tested too much? That’s why starting to question certain beliefs I hold.

Thanks for feedback, it’s something I want to write a little more about and need wider input/challenging opinions :)