Discover more from Effective Software Testing
One of the biggest truths when it comes to developer testing is that it has to be easy!
If it's not easy, we'll simply don't do it. We'll find lots of different excuses, such as "I don't have time", or "Ah, I don't really need to test this", or "It's not worth it". But the thing is: no one says these things if writing the test takes just a few minutes.
It should be easy to unit test any component of the system.
It should be be easy to control any part of the system through, say, mocking.
It should be easy to write integration tests, without developers having to write dozens of boilerplate lines of code.
It should be easy to build up complex entities with a few lines of code.
It should be easy to set up data in the database if the test requires it.
It should be easy to write larger e2e tests if the team decides to go for it.
It should be easy to simulate external systems and their contracts.
If you want your team to write tests all the time, you don't need much. Just make it easy. In the next post, I'll show you examples.
It has to be easy!
I resonate with this post a lot, difficulty of testing has been one of the large barriers my team has had in the past couple of years. My team works on data pipelines that integrate datasets from many different sources, and seeding tests is our biggest challenge because the cardinality of edge cases is so high.
I am currently doing some research and testing with a different paradigm of testing, using live statistical validations rather than the very logical and straight forward "this function takes input x and outputs y, validate y is expected". The main problem we are addressing here is generating combinations of inputs is really hard. Would love to chat with you if you have any insights in this field if you get the chance!
professor, in regards of it has to be easy.. do you have an advice of how to test authentication for apis without duplication. I mean, when we define an api, we add some configuration in that api to inform it can only be accessed by authorized users. So in my tests I have to write a unit test for the authorized and unauthorized case for this api. This goes over and over for every api..