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

Tests using RUnit #21

Open
melpetera opened this issue Dec 2, 2020 · 8 comments
Open

Tests using RUnit #21

melpetera opened this issue Dec 2, 2020 · 8 comments

Comments

@melpetera
Copy link
Member

Hi there,

While proposing some changes in the Batch correction module (#20 ), I ran into difficulties to update what has been put in the "runit" folder. I undestand that this part is dedicated to unit testing with at least one test dataset, but the thing is I am not familiar with the structure here, so I did not manage to know what should be updated to correspond to the modifications that have been made in the "3L" methodology. Truth is I don't know how to run these tests neither.

@pkrog what do you think about it?

@pkrog
Copy link
Member

pkrog commented Dec 4, 2020

There is a small section about running the RUnit tests inside the README file (See "Tests" chapter).
You have to run the script runit/batchcorrection_runtests.R. So the command is:

Rscript runit/batchcorrection_runtests.R

Give it a try and see if it prints you warning and/or errors.

@melpetera
Copy link
Member Author

Hi @pkrog
Thanks for the reply. The problem is that in the dev branch, you made some changes to the runitfolder (now called "test") but no update of the batchcorrection_runtests.R. It seems there are quiet a few changes to be done but I am not familiar with this. The files in the res folder (that seems to correspond to the old output one) are quite different from the previous ones. I imagine that the test scripts would need quite a few changes? But again, I am not familiar with this testing process so even if I tryed investigating the question looking at the old and new versions of this testing suit, I am a little confused here...
Any suggestion?

@pkrog
Copy link
Member

pkrog commented Jan 12, 2021

I've looked at your branch Dusting_and_update, but I don't see the test folder, or the runit folder.

@melpetera
Copy link
Member Author

melpetera commented Jan 12, 2021

Yes, in fact I have just removed it a few minutes ago in 1944b07 : I was about to make a comment about it when someone grabbed me for an unplanned meeting.

Truth is I have a training next week, so I was going to suggest to remove the tests for now to be able to validate a version I hope to get on prod instance quickly, and then to create a dedicated Runit branch based on first a reverse commit of 1944b07

This way I can make people use the latest fonctionalities next week and have a dedicated branch for the RUnit question.

Is this ok for you?

@pkrog
Copy link
Member

pkrog commented Jan 12, 2021

It's better to let the folder inside the project, and comment out the code that runs it.
Inside the file .travis.yml, just comment out the following line:

    - PLANEMO=

but left unchanged the line with PLANEMO=yes,
and those tests won't be run on Travis.

@melpetera
Copy link
Member Author

melpetera commented Jan 12, 2021

Are you sure? Wouldn't it be a problem since it is going to be merged then in the master branch and then put in the main Galaxy toolshed? I have no doubt it will be no problem to pass Travis tests and no impact on the tool run is expected. However I am not too sure whether a public deposit with not-functionnal RUnit tests is a good idea.

Or maybe there are common ways to tag part of the content to be an "in progress" stuff that should not be taken into consideration by people that would get the latest prod version deposit? I am not very familiar to common practices regarding this kind of things.

@pkrog
Copy link
Member

pkrog commented Jan 12, 2021

The galaxy toolshed is another thing, when you publish your tool into it, you must not put this test folder since it will not be used by Galaxy. Only the tests inside the XML and the test-data folder go into the Galaxy toolshed.
You won't put the Travis files (.travis.yml and travis-tests) either inside the Galaxy toolshed by the way, nor the Makefile file.
So, yes, it's OK if you let the folder test as is, and comment out the line inside .travis.yml.

@melpetera
Copy link
Member Author

Okay, thank you! I will make the modifications accordingly.

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

No branches or pull requests

2 participants