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..
- You do the authorization step at every test, but you make it transparent to the developer, so that they don't have to "remember to do it" all the time. This may be costly time-wise, but usually it's fine.
- You can add a way in your app to "skip" this authentication. So, you have a test suite that exercises the authentication flow, but in all the others, you simply skip this step. This makes your test a bit different from production, but the feedback might be as good.
Yes, it does. I think it could be applied in production code as well if we take in consideration that all apis should be authenticated unless we say otherwise. Like in linux where a user can only access a directory/file if the permission was given.
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..
Hey, Guilherme! I see a few options:
- You do the authorization step at every test, but you make it transparent to the developer, so that they don't have to "remember to do it" all the time. This may be costly time-wise, but usually it's fine.
- You can add a way in your app to "skip" this authentication. So, you have a test suite that exercises the authentication flow, but in all the others, you simply skip this step. This makes your test a bit different from production, but the feedback might be as good.
Does it make sense?
Yes, it does. I think it could be applied in production code as well if we take in consideration that all apis should be authenticated unless we say otherwise. Like in linux where a user can only access a directory/file if the permission was given.
I liked your insight. Thanks!