Skip to content
loading...

re: Test Driven Development - not Unit Test Driven Development VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Testing Lambda functions is an interesting world because if they truly are only a single function (doing a single thing), then I agree that unit + ...

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 😀

Hi Vlad,

You are absolutely correct in that - if you are writing lower level unit tests and then higher level tests - there will be substantial overlap between the two layers. This is the same for applying automated testing to any codebase if you are starting with unit tests.

Are these unit tests obsolete? Maybe.

Are they redundant? Probably.

Could you refactor the unit tests to remove some of the redundancy? Definitely.

Should you delete them? Almost definitely not :-)

As you said the "granular feedback" of the unit test suite is the main reason I keep these tests around. The secondary reason would be the ability to exert more exact control around the error conditions that might be harder to setup in higher level tests.

In an ideal world, a regression in behaviour in an application should only break a single test. Practically, a single regression might break a couple of unit tests and a corresponding higher level test. This is annoying, but I've not found a good way to get the fast feedback from unit tests (and especially TDD) AND the higher confidence from higher level tests AND the lack of redundancy when they are combined in a single codebase.

I've seen quite a few teams stuck with many thousands of unit tests that were an absolute drag on their ability to work on the codebase and with no way to redesign the test suite to allow them to spend more time building code and less time repairing the suite. Test suite design and maintenance is certainly not a solved problem within the industry.

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 🙂

code of conduct - report abuse