pyWhat icon indicating copy to clipboard operation
pyWhat copied to clipboard

Improve tests

Open ghost opened this issue 3 years ago • 10 comments

We have a lot of tests that were just copy-pasted from each other. Because of that, test files are long.

What do you need to do? Take a look at our tests and try to add some helper functions, make tests shorter.

ghost avatar Oct 09 '21 18:10 ghost

Hi, can I take this?

deepakdinesh1123 avatar Oct 10 '21 00:10 deepakdinesh1123

Hi, can I take this?

Apparently, there is already draft PR: https://github.com/bee-san/pyWhat/pull/202

ghost avatar Oct 10 '21 08:10 ghost

Right now I'm only working on test_regex_identifier.py, so if you want you can work on some other files @deepakdinesh1123!

jyooru avatar Oct 10 '21 09:10 jyooru

And while we are discussing tests files, I'm not sure about the usefulness of some tests in test_click.py. We do test that all regex work in test_regex_identifier.py and #202 plans to make it easier which is great. But there is a lot of repetition in test_click.py, every regex is also tested there. Either as an arg or from the fixture file. I added some tests myself, as I seemed to be the way it was done but I'm not sure it is useful and pretty sure it could at least be simplified. Any thoughts? Maybe I'm just missing something.

Originally posted by @PabloLec in https://github.com/bee-san/pyWhat/issues/206#issuecomment-940230796

When #202 gets merged with examples alongside in the database, we could maybe take those, write it to a file and run the file against pyWhat to verify that regex works if match is put in a file? But we also need to test boundaryless, so matches in between of something else..

Originally posted by @amadejpapez in https://github.com/bee-san/pyWhat/issues/206#issuecomment-940255254

PabloLec avatar Oct 11 '21 18:10 PabloLec

I guess testing boundaryless and every other CLI arguments could still be made in test_click.py of course. Probably against a permanent fixture file, meaning we would not have to add every example to this fixture file. Since everything tricky will be tested, we know the parsing part works and we could only test regex one by one with #202 method.

And we could still make a test to just iterate over all regex and respective examples and pass them as args to make sure everything works fine.

PabloLec avatar Oct 11 '21 18:10 PabloLec

hello

Saacket avatar Oct 17 '21 09:10 Saacket

I'm starting to work on parameterizing test_click.py now.

And we could still make a test to just iterate over all regex and respective examples and pass them as args to make sure everything works fine.

I could implement this.

jyooru avatar Oct 18 '21 07:10 jyooru

Hey @jyooru, are you still working on click tests?

ghost avatar Nov 03 '21 08:11 ghost

Sorry, I forgot about this. I've cleaned up a little bit on my branch refactor/test/click.

After looking at my changes, I think that passing each regex as args is going to be a better idea than continuing to use a fixture file. This also means that each test could be automatically generated like in #202, instead of using a manually updated list that I implemented on my branch.

I'm happy to implement each regex being passed as args.

jyooru avatar Nov 04 '21 06:11 jyooru

Sorry, I forgot about this. I've cleaned up a little bit on my branch refactor/test/click.

After looking at my changes, I think that passing each regex as args is going to be a better idea than continuing to use a fixture file. This also means that each test could be automatically generated like in #202, instead of using a manually updated list that I implemented on my branch.

I'm happy to implement each regex being passed as args.

Actually, I am thinking that regex tests should be removed from test_click.py since we already test regex database. Only CLI related tests should be left.

ghost avatar Nov 04 '21 08:11 ghost