I am skeptical about this proposal. While this might work for your package, I am afraid it won't work generally and trying to do something like this is wasted energy. Let me explain. When RubyGems were designed in 2004, TDD, BDD and testing in general was becoming good practice. Therefore they decided that it is good idea to ship code together with its test suite and also execute the tests during installation. So you were supposed to be able to run something like "gem install -t foo". But it proven to be problematic. Generally this "-t" option never worked and could be used just for the most naive test suites. So the option was removed [1]. Nowadays, more and more gem packages does not ship their tests suites and even the support for shipping the test suites is deprecated [2]. If you want to understand how complex it might be to run the test suite of some packages, I welcome you to explore the %check sections of rubygem- packages. Some are simple, but most are not that simple, starting with small differences as load path, ending with test suites which needs to run various servers or check against cloud services. Not mentioning test matrices. Also, for all these tests we usually try to simulate the environment as similar as possible to upstream repository, because this is how these test suites are designed. It would be even harder to execute the test suites against installed packages. Vít [1] https://github.com/rubygems/rubygems/commit/429f883210f8b2b38ea310f7fc6636cd0e456d5c [2] https://github.com/rubygems/rubygems/issues/735 Dne 05. 07. 19 v 19:49 Neil Horman napsal(a): > Hey all- > I was starting to setup CI for one of my packages in Fedora (cscope), > which requires that I have access to the sources to run my test (cscope uses its > own source tree to search for various symbols to confirm that its working > properly). Getting the sources in the CI environment is a bit of a pain, so I > started working on trying to do this by creating a test subpackage (specifically > named -citest) to package up the sources solely for the purpose of getting them > installed and available during CI runs. It occured to me that this offers > several advantages, among them: > 1) the ability to codify dependencies within the ame spec file, rather than > having to copy them to the test.yml file, and keep them in sync > > 2) The ability to use a file format (rpm spec files) that I'm more familiar with > > 3) Easy access to tests that are embedded in the source tree > > 4) minimizing the test harness setup in test.yml > > For anyone interested, I've got a pull request started here: > https://src.fedoraproject.org/rpms/cscope/pull-request/2 > > If anyone wants to take a look at the changes I had to make to do this (fair > warning, its still very rough). > > That all said, I was wondering if perhaps there was general interest in making > this kind of test model somewhat more formal (i.e. creating an rpm macro library > to make test package generation a bit easier, creating a standard entry point to > run tests, etc). > > Thoughts welcome > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
