Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using PSLRUNTEST #100

Open
cjprieb opened this issue Sep 30, 2019 · 3 comments
Open

Using PSLRUNTEST #100

cjprieb opened this issue Sep 30, 2019 · 3 comments
Labels

Comments

@cjprieb
Copy link
Contributor

cjprieb commented Sep 30, 2019

I'd like to experiment with the PSL Run Test options, but the release notes mention that they require custom code in Profile. Can you share the custom code that's in MRPC121? Do you have examples on what the test code looks like?

@SOliveiraING
Copy link
Collaborator

Hi @cjprieb is this question still valid? if so let us know.

@cjprieb
Copy link
Contributor Author

cjprieb commented Oct 22, 2022

I ended up rolling my own version of unit tests in the plugin, but I am still curious how your team implemented it.

@SOliveiraING
Copy link
Collaborator

I will document that in the future (may take sometime) but for now leave here some highlights.

As mentioned in CHANGELOG we have introduced the below configs:

"psl.customTasks": [
	{
		"command": "runCoverage",
		"mrpcID": "^ZMRPC121",
		"request": "PSLRUNTESTC"
	},
	{
		"command": "runTest",
		"mrpcID": "^ZMRPC121",
		"request": "PSLRUNTEST"
	}
]

On the host side we have created ZMRPC121 (with same signature of MRPC121, since we cannot extend without customising core) and implemented these 2 requests.

We execute the below steps:

  1. The temporary file with the code is renamed to its proper name.
  2. The file is compiled $$run^PSLC(), any compilation error returns immediately the output of compile.
  3. Since we compile the file in a temporary directory we update the gtmroutines variable to include temporary directory as first source for routines. And execute the tests $gtm_dist/mumps -run ZPslUtTestCase/ZPslUtTestSuite XXXXXXXX > output.log depending on input may be test suite or test case, may have coverage requirements or not (--coverage --coverageDetails) and redirect the output to a file. Coverage is a total custom implementation but luckily Profile Framework has implemented something that achieves the same this year.
  4. We read and return the content in the output.

Since we extend the framework components PslUtTestCase, PslUtTestSuite and PslUtTestResult we control the output of the execution of tests, example below

[INFO][21:57:47]    … ▶ UtcZRPC1010.psl RUN in docker
[INFO][21:57:54]    Test Results> 

Test #: RESULT (time) testCase.test message

Test Coverage: 
  23.80% - ZINGAuthenticate
 100.00% - ZINGInterfaceUtilities
  95.65% - ZRPC1010

Report Summary:
********
Tests Run:     17
Tests Passed:  17
********

We have skipped any details of tests that passed and only report failures, errors and skipped files.

We also get in the menu the list of compiled routines that were covered to select from, which will be fetched from Host and the coverage will be display on the mumps code highlighting which mumps code is covered and which is not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants