-
Notifications
You must be signed in to change notification settings - Fork 310
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
Rethink test strategy #755
Comments
To guard against OS X specific issues like #1233. Do not use CircleCI as another service here as they only offer "1 macOS container and up to 500 build minutes per month" which is far too little for our test suite which currently takes > 20 minutes per PR (also see issue #755). Signed-off-by: Sebastian Schuberth <sebastian.schuberth@here.com>
To guard against OS X specific issues like #1233. Do not use CircleCI as another service here as they only offer "1 macOS container and up to 500 build minutes per month" which is far too little for our test suite which currently takes > 20 minutes per PR (also see issue #755). Signed-off-by: Sebastian Schuberth <sebastian.schuberth@here.com>
To guard against OS X specific issues like #1233. Do not use CircleCI as another service here as they only offer "1 macOS container and up to 500 build minutes per month" which is far too little for our test suite which currently takes > 20 minutes per PR (also see issue #755). Signed-off-by: Sebastian Schuberth <sebastian.schuberth@here.com>
To guard against OS X specific issues like #1233. Do not use CircleCI as another service here as they only offer "1 macOS container and up to 500 build minutes per month" which is far too little for our test suite which currently takes > 20 minutes per PR (also see issue #755). Signed-off-by: Sebastian Schuberth <sebastian.schuberth@here.com>
To guard against OS X specific issues like #1233. Do not use CircleCI as another service here as they only offer "1 macOS container and up to 500 build minutes per month" which is far too little for our test suite which currently takes > 20 minutes per PR (also see issue #755). Signed-off-by: Sebastian Schuberth <sebastian.schuberth@here.com>
To guard against OS X specific issues like #1233. Do not use CircleCI as another service here as they only offer "1 macOS container and up to 500 build minutes per month" which is far too little for our test suite which currently takes > 20 minutes per PR (also see issue #755). Signed-off-by: Sebastian Schuberth <sebastian.schuberth@here.com>
To guard against OS X specific issues like #1233. Do not use CircleCI as another service here as they only offer "1 macOS container and up to 500 build minutes per month" which is far too little for our test suite which currently takes > 20 minutes per PR (also see issue #755). Signed-off-by: Sebastian Schuberth <sebastian.schuberth@here.com>
To guard against OS X specific issues like #1233. Do not use CircleCI as another service here as they only offer "1 macOS container and up to 500 build minutes per month" which is far too little for our test suite which currently takes > 20 minutes per PR (also see issue #755). Signed-off-by: Sebastian Schuberth <sebastian.schuberth@here.com>
To guard against OS X specific issues like #1233. Do not use CircleCI as another service here as they only offer "1 macOS container and up to 500 build minutes per month" which is far too little for our test suite which currently takes > 20 minutes per PR (also see issue #755). Signed-off-by: Sebastian Schuberth <sebastian.schuberth@here.com>
To guard against OS X specific issues like #1233. Do not use CircleCI as another service here as they only offer "1 macOS container and up to 500 build minutes per month" which is far too little for our test suite which currently takes > 20 minutes per PR (also see issue #755). Signed-off-by: Sebastian Schuberth <sebastian.schuberth@bosch-si.com>
These are not really (unit) tests on small units of code, but tests that perform rather length operations on VCS working trees with the help of external CLI tools. As a consequence, reclassify them as functional tests, which fits better, but probably still needs some clean-up in the context of #755. Signed-off-by: Sebastian Schuberth <sebastian.schuberth@bosch-si.com>
These are not really (unit) tests on small units of code, but tests that perform rather lengthy operations on VCS working trees with the help of external CLI tools. As a consequence, reclassify them as functional tests, which fits better, but probably still needs some clean-up in the context of #755. Signed-off-by: Sebastian Schuberth <sebastian.schuberth@bosch-si.com>
These are not really (unit) tests on small units of code, but tests that perform rather lengthy operations on VCS working trees with the help of external CLI tools. As a consequence, reclassify them as functional tests, which fits better, but probably still needs some clean-up in the context of #755. Signed-off-by: Sebastian Schuberth <sebastian.schuberth@bosch-si.com>
Also see #2450 (comment). |
Another issue with the YAML based tests is that it is difficult to fix them when the model is changed. Issues with expected result files are discovered only when executing tests, and manually fixing them can be a lot of effort.
To amount of code required to create this test data could be reduced by creating a simple DSL to create ORT results. |
One can use DSL builder in Kotlin to build expected results : |
Indeed, and a start was committed with 0f26841. |
Closed as part of backlog grooming. Feel free to comment if you would like to contribute to this. |
Currently most functional tests work by comparing analyzer or scan results with a YAML file that contains the expected serialized result.
The problem with this approach is, that comparing the complete file often compares much more than is required to test a single feature. As a result simple refactorings can break a lot of tests which do not test the refactored code, and it is required to change a lot of YAML test files to fix this, which makes refactorings very expensive.
A way to fix this would be to reduce the amount of YAML based tests and to make sure that a test for a specific feature only tests this feature and nothing else. This would make it necessary to write a lot more code in the tests themselves, but with the gain that refactorings become cheaper and issues with related tests can often be found at compile time, not only when executing tests.
The text was updated successfully, but these errors were encountered: