|
|
If you develop new features in Alya, you should regularly add new tests to the testsuite to validate that such a feature works as expected, but also that nobody breaks this feature when contributing to Alya. We won't accept complaints from someone whose Alya features are not evaluated by the testsuite, because it is not reasonably possible to determine all the interweaving between Alya components and the impact of a modification on the whole code behavior without automatic testing. Nevertheless, regarding the developer, we don't validate either the following assertion: _because Alya passes the testsuite, my contribution is of good quality_. Any contribution should be thought, designed carefully without interfering with the normal behavior of Alya, and if possible mentioned to the design team through the issues.
|
|
|
If you develop new features in Alya, you should regularly add new tests to the testsuite to validate that such a feature works as expected, but also that nobody breaks this feature when contributing to Alya. We won't accept complaints from someone whose Alya features are not evaluated by the testsuite, because it is not reasonably possible to determine all the interweaving between Alya components and the impact of a modification on the whole code behavior without automatic testing. Nevertheless, regarding the developer, we don't validate either the following assertion: _because Alya passes the testsuite, my contribution is of good quality_. Any contribution should be thought, designed carefully without interfering with the normal behavior of Alya, and if possible mentioned to the design team through the issues, not relying only on the testsuite result.
|
|
|
|
|
|
# Add a new test or modify an existing one
|
|
|
|
... | ... | @@ -28,5 +28,18 @@ svn commit |
|
|
|
|
|
## Modify an existing test
|
|
|
|
|
|
Go to the test directory, and modify the test files and the test .json consequently.
|
|
|
Then, commit, and run a testsuite on your test branch to validate your changes. Once it's done, ask the admin to reintegrate your changes. The admin automatically receive the testsuite emails (if you run it on your machine) so you won't have to justify that it ran with success. |
|
|
\ No newline at end of file |
|
|
Go to the test directory, and modify the test files and the test `.json` consequently.
|
|
|
Then, commit, and run a testsuite on your test branch to validate your changes. Once it's done, ask the admin to reintegrate your changes. The admin automatically receives the testsuite emails (if you run it on your machine) so you won't have to justify that it ran with success.
|
|
|
|
|
|
## Add a new test
|
|
|
|
|
|
Go to the test directory that is the most appropriate (for instance `fast/nastin` if your test is related to a nastin feature), and add a new directory and `.json` file the same way it is done for the existing tests.
|
|
|
Add the files to the svn repository and commit them. Follow the same process as for modifying a test.
|
|
|
|
|
|
If your test needs to be discarded for specific builds (for instance, your test depends on i4 and you want to discard it for i8), you will have to modify the `AlyaTS/Trunk/ServerConfig/` related configuration file and add your test to the list of excluded tests. Since you cannot modify the Trunk directly, you will need to create a new branch:
|
|
|
|
|
|
```
|
|
|
svn copy svn+ssh://bsc21***@mn3.bsc.es/gpfs/projects/bsc21/svnroot/AlyaTS/Trunk svn+ssh://bsc21***@mn3.bsc.es/gpfs/projects/bsc21/svnroot/AlyaTS/branches/[mytestsuite]
|
|
|
```
|
|
|
|
|
|
modify and commit the files, configure and run the testsuite from this branch `mytestsuite` and ask your admin to reintegrate it. |
|
|
\ No newline at end of file |