Hi James, all,

I can't remain silent. There's a counter-offering. We have an alternative
which may sort the whole thing. The peppersoup project has developed a
maintainable functional test set based on gherkin. It has over 600 business
use cases going way beyond the surface.  It has got to a point to be easy
to make available to the community, what's more, be part of the development
process and eventually replace the integration tests with a better version.
Meanwhile -I hope I won't hurt feelings- but JMeter isn't the right tool
for functional testing. Although it was possible to use it for that, it
would look sort of unprofessional.

M/


On Thu, Feb 1, 2024 at 10:52 AM ANJIL CHINNAPATHLOLLA <[email protected]>
wrote:

> Hi James,
>
>
>
> In another week I will have the PR created.
>
> Making the test suite more generic to be consumable by wider community.
>
>
>
>
>
> Thanks & Regards,
>
> Anjil ,
>
> Power Systems Performance
>
>
>
> “Success is not the result of spontaneous combustion. You must set
> yourself on fire.”
>
>
>
> *From: *James Dailey <[email protected]>
> *Date: *Thursday, 1 February 2024 at 1:10 PM
> *To: *[email protected] <[email protected]>, ANJIL
> CHINNAPATHLOLLA <[email protected]>
> *Subject: *[EXTERNAL] Re: API Test Case for Fineract
>
> To bring this to the top, is there a PR for this? Do we now have jMeter
> asserts written that we can add to? Let's make it a default test that can
> be skipped . ? On Thu, Jan 18, 2024 at 1: 01 AM Arnold Galovics <arnold@
> apache. org> wrote: Hi
>
> ZjQcmQRYFpfptBannerStart
>
> *This Message Is From an External Sender *
>
> This message came from outside your organization.
>
>
> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJGw4rNbuq962SqFAmKzTse2VXoqajLDlauKunCCMeHBtSZ7S12GwV0WLLjAseYE2Pzj-YBoB3dyNM6JBuIlV9_etrOinesLw3_I58ysRkaUDCelFfizWQ$>
>
> Report Suspicious
> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJGw4rNbuq962SqFAmKzTse2VXoqajLDlauKunCCMeHBtSZ7S12GwV0WLLjAseYE2Pzj-YBoB3dyNM6JBuIlV9_etrOinesLw3_I58ysRkaUDCelFfizWQ$>
>
>
>
>
>
> ZjQcmQRYFpfptBannerEnd
>
> To bring this to the top, is there a PR for this?  Do we now have jMeter
> asserts written that we can add to?
>
>
>
> Let's make it a default test that can be skipped . ?
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jan 18, 2024 at 1:01 AM Arnold Galovics <[email protected]> wrote:
>
> Hi Victor, James,
>
>
>
> Just to circle back on one of the points - "I think the better approach is
> to have a manual kick off as suggested by Victor.".
>
>
>
> Let's be careful with this approach. I've seen this practice many many
> times and often the end result is that these suites are being left alone
> and become super incompatible with the latest version of the application
> over time, simply because you cannot enforce this suite to be kept
> compatible.
>
>
>
> Best,
>
> Arnold
>
>
>
>
>
>
>
> On Tue, Jan 16, 2024 at 9:51 PM James Dailey <[email protected]>
> wrote:
>
> Thanks Anjil - I think this is a great idea and want to see your PR.
>
>
>
> Victor.  As I noted in October 2020, one important principle is to make
> sure this is maintainable by the project. (see comments
> https://issues.apache.org/jira/browse/FINERACT-1170  )  To that end, the
> documentation and set up need to be reviewed before acceptance.  It has to
> be relatively easy to understand and maintain, and the initial contribution
> should be documented enough to be maintained by someone other than Anjil,
> although I fully hope that Anjil will remain involved 100% .
>
>
>
> Arnold has raised the importance of ensuring that it doesn't add to the
> build time.  I agree.  My comment in 2020 was to include it as part of the
> build (CI), but I think the better approach is to have a manual kick off as
> suggested by Victor.
>
>
>
> Arnold has also asked about the completeness, reliability, and quality of
> the tests.  I would expect that we cannot know that until we see the
> contribution that is proposed.  We should then spend some time - i.e.
> longer than the minimum time and less than a month - to fully review and
> accept.
>
>
>
> Size of contribution?  One of the check marks in the PR says "not a large
> code dump".  Does this qualify as a large code dump?   If so, then it needs
> additional review and acceptance. That can be part of the above extended
> review period.
>
>
>
> Moreover, once this is in place, we then would add an expectation that all
> new features would also need an assertion in the jmeter setup, prior to PR
> acceptance.  We would need to include jmeter assertion as a required part
> of the PR.
>
>
>
>
>
>
>
> On Tue, Jan 16, 2024 at 12:20 PM VICTOR MANUEL ROMERO RODRIGUEZ <
> [email protected]> wrote:
>
> Also I am bringing these Jira tickets into the conversation table
> https://issues.apache.org/jira/browse/FINERACT-1170 and
> https://issues.apache.org/jira/browse/FINERACT-1238
>
>
>
> Regards
>
>
>
> Victor
>
>
>
>
>
> El mar, 16 ene 2024 a las 9:59, VICTOR MANUEL ROMERO RODRIGUEZ (<
> [email protected]>) escribió:
>
> Hello Arnold,
>
>
>
> - I am trying to show where to put the JMeter in the project structure,
> not in a particular order.
>
> - The integration suite test cases are listed anywhere or it creates a
> test case report that can be viewed or exported for later review?
>
> - JMeter is not for adding an extra layer/step during the build process,
> but for being executed on demand.
>
> - About flakiness ... I don't get the point? Can it be explained a little
> bit more?
>
> - Proposal of another folder in the Fineract project is to add the Jmeter
> assets independently.
>
>
>
> Regards
>
>
>
> El mar, 16 ene 2024 a las 1:08, Arnold Galovics (<[email protected]>)
> escribió:
>
> Hi guys,
>
>
>
> Despite the fact that I like extra test coverage, let's slow down a little
> bit before rushing any integration.
>
>
>
> I'd have a couple of questions about these tests:
>
> - Victor, you're saying these tests should come before fineract-provider,
> so within the regular build process yet these are JMeter, performance
> related test cases. So what are the assertions in these? I'm a little
> confused about what these are.
>
> - Did we do any cross-check with our integration suite if these test cases
> are covered and we are not introducing duplication unnecessarily?
>
> - The build times are already slower than ever, did we evaluate how much
> increase these would mean?
>
> - How about flakyness on these tests?
>
> - I'm also interested in the general quality of the tests because
> maintainability on most of the existing integration test suite is difficult.
>
>
>
> Again, I'm not against any new test case/suite introduction, but let's
> clarify the benefits and the drawbacks.
>
>
>
> Thanks.
>
> Best,
>
> Arnold
>
>
>
> On Tue, Jan 16, 2024 at 6:44 AM VICTOR MANUEL ROMERO RODRIGUEZ <
> [email protected]> wrote:
>
> Hello Anjil,
>
>
>
> Version 1.9.0 is tagged at:
>
>
>
> https://github.com/apache/fineract/tree/1.9.0
>
>
>
> Regards
>
>
>
> Victor
>
>
>
> El lun, 15 ene 2024 a las 23:42, ANJIL CHINNAPATHLOLLA (<
> [email protected]>) escribió:
>
> Thanks Victor / Mugabe,
>
>
>
> I will verify the test suite against 1.9.0, make necessary minor changes
> wherever required and raise the PR.
>
>
>
>
>
> Thanks & Regards,
>
> Anjil ,
>
> Power Systems Performance
>
>
>
> *From: *Magezi Arthur <[email protected]>
> *Date: *Tuesday, 16 January 2024 at 3:35 AM
> *To: *[email protected] <[email protected]>
> *Subject: *[EXTERNAL] Re: API Test Case for Fineract
>
> Great proposal here. Anjil this would definitely be of great help. MUGABE
> MAGEZI ARTHUR Software Developer and Process Management Consultant emails:
> artmagezi@ gmail. com atmagezi@ yahoo. co. uk Mob: +256704901261
> facebook: Magezi ArthurSkype: marthur26The
>
> Great proposal here. Anjil this would definitely be of great help.
>
> *MUGABE MAGEZI ARTHUR*
>
> Software Developer and
>
> Process Management Consultant
>
> emails:
>
> *[email protected]* <[email protected]>
>
> *[email protected] <[email protected]>*
>
> Mob: +256704901261
>
> facebook: Magezi Arthur
>
> Skype: marthur26
>
>
>
> The Struggle the doesn't break you will make you, if you hold a little
> longer under that fire you      will certainly come out as Gold
>
>
>
>
>
> On Mon, 15 Jan 2024 at 20:37, VICTOR MANUEL ROMERO RODRIGUEZ <
> [email protected]> wrote:
>
> Hello Fineract Community,
>
>
>
> What do you think about integrating these tests on Apache Fineract. The
> Apache JMeter Tests can be included in this way:
>
>
>
> Apache Fineract
>
> |
>
> ------Functional Test (Anjil contribution)
>
> |
>
> -----fineract-provider
>
>
>
> Do you have any comments about this proposal?
>
>
>
> Regards
>
>
>
> Victor Romero
>
>
>
> El vie, 12 ene 2024 a las 15:06, VICTOR MANUEL ROMERO RODRIGUEZ (<
> [email protected]>) escribió:
>
> Hello Anjil,
>
>
>
> I think it suits perfectly. Because it will help us to evaluate, verify,
> test the functionality between release. I.E. a possible 1.8.5 release and
> the 1.9.0.
>
>
>
> And this is important because with the results the community can be aware
> of the changes requiered on its applicatons.
>
>
>
> I hope to listen (read) other community members opinion.
>
>
>
> Regards
>
>
>
> Victor
>
> El vie., 12 de enero de 2024 2:12 p. m., ANJIL CHINNAPATHLOLLA <
> [email protected]> escribió:
>
> Hi Victor and community members,
>
>
>
> I have a JMeter based test suite of Fineract (1.8.4) REST APIs put
> together for the performance evaluation of our Infrastructure. I have them
> classified into two categories
>
>    1. Setup Test suite – This contains set of APIs to setup a banking
>    environment, define products etc.
>    2. Transactions test suite – This contains various frequently run
>    account operations (Savings Deposits, withdrawals, balance enquiries, loan
>    disbursal etc)
>
>
>
> Posting below a screenshot of the test suits which can accommodate more
> test cases into respective groups as the need arises. The test suit serves
> the purpose of evaluating both functional as well as performance aspects of
> the use cases across the builds. If we think this helps with the purpose
> you are looking for below, I can contribute the test suits into the
> Fineract GitHub (With appropriate modifications to be consumable by the
> community).
>
>
>
> *Error! Filename not specified.*
>
>
>
>
>
> Thanks & Regards,
>
> Anjil ,
>
> Power Systems Performance
>
>
>
> “Success is not the result of spontaneous combustion. You must set
> yourself on fire.”
>
>
>
> *From: *VICTOR MANUEL ROMERO RODRIGUEZ <[email protected]>
> *Date: *Saturday, 13 January 2024 at 12:18 AM
> *To: *Dev <[email protected]>
> *Subject: *[EXTERNAL] API Test Case for Fineract
>
> Hello Fineract Community, I want to know if there is any Bundle of Test
> Cases for Apache Fineract API Rest that can be used to test the Apache
> Fineract vanilla version. - Create data codes (genders) - Create offices -
> Create delinquency bucket-
>
> Hello Fineract Community,
>
>
>
> I want to know if there is any Bundle of Test Cases for Apache Fineract
> API Rest that can be used to test the Apache Fineract vanilla version.
>
>
>
> - Create data codes (genders)
>
> - Create offices
>
> - Create delinquency bucket
>
> - Create loan product
>
> - Create client
>
> - Create loan account (application, approval, disbursement)
>
> - Create repayments.
>
> - Etc
>
>
>
> I know that we have in the source code testing case (unit/integration test
> cases) that are executed as part of the building process, but this question
> is more related to a bundle/orchestration of  complete functional flows in
> order to make sure that the nightly build or the release has a functional
> quality check of its REST APIs.
>
>
>
> Regards
>
>
>
> Victor
>
>

Reply via email to