[GitHub] [fineract] danishjamal104 commented on pull request #1828: invalid field name fixed in GetDataTablesResponse (FINERACT-1372)

[GitBox <gi...@apache.org>]

danishjamal104 commented on pull request #1828:
URL: https://github.com/apache/fineract/pull/1828#issuecomment-899006457


   > Hi Danish - many thanks for all of your pull requests fixing the Swagger client API definitions - this is great work! What I was thinking about is: how do we best review these and ensure the fixes are correct. One option would be for me to simply look at the changes you’ve made and compare that to the function signature manually. That of course works, but is pretty error-prone and manual: if we make any mistakes in comparison, then there may still be differences and the Swagger client will not work. Also this is “one-off”: if there are any changes in the future to either Swagger definition or to the function signature, there is no guarantee they will stay in synch. To me, the real solution would be to actually write some test cases that use the generated Swagger client to call the APIs. If they work, then clearly the definitions are correct as well. If they don’t work, then there’s still some difference (or some other problem) with the Swagger definitions. The other be
 nefit with this would be that these test cases could then be part of the automatic build, and ensure the APIs remain working also in the future. In fact, we’ve before discussed that it would make sense to move all the current integration tests (which work via direct REST calls to the API) to be done through the Swagger generated client instead. Would be great to get your thoughts - if there’s an easier way to make sure things are “in synch” then let’s consider that as well. Alternatively, if you think writing tests makes sense as an approach, would you have time to also write some simple test cases through the generated Swagger client for the fixes that you submit? That way their correctness would be automatically verified both now and in the future. Cc’ing the Dev list for any other ideas/suggestions as well Thanks Best regards Petri
   > […](#)
   
   
   hey @ptuomola , first of all thanks for taking a look at my PR. As far testing is considered their is already test cases defined for different endpoints which internally make use of fineract client. Take a look at below SS it gets the FIneractClient instance and uses is for making request to different endpoints.
   The main issue arises when we test the client api using more data. For example, In earlier stage when I tested the client API for getting client info,  it was working fine but as soon as I linked it with the group then the exception is thrown, so the main issue was that the generated class defines `groups` field as a list of String and the api returned the empty group list but when the client was linked with group then the list of groups object was returned. Hence the test cases wasn't able to recognise the error and was passing it. 
   Summarising the example, `[]` is a valid `List<String>` and `List<Groups>`. So when  api sends `List<Groups>` then it throws error. This is one of the example, as I was integrating the generated client sdk I encountered many  such type issues which was initially working fine but later failed.
   
   
   ![Screenshot 2021-08-15 at 12 21 09 PM](https://user-images.githubusercontent.com/31315800/129469816-4f2a5e92-399f-4d47-9062-f16943b95ee6.png)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@fineract.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org