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

test_license.py issues #231

Open
kkrolczyk opened this issue Nov 2, 2022 · 1 comment
Open

test_license.py issues #231

kkrolczyk opened this issue Nov 2, 2022 · 1 comment

Comments

@kkrolczyk
Copy link
Contributor

We'd like to test if empty or invalid string as license expression raises error.

@pytest.mark.parametrize('lic_expr', ["This is not a list", ])
def test_fail_on_invalid_str_license_expression(parse_simple):
    with pytest.raises(FlictError):  #  FIXME flict does not fail here
        pass

@pytest.mark.parametrize('lic_expr', [[], ])
def test_fail_on_empty_license_expression(parse_simple):
    with pytest.raises(FlictError) as err:
        pass
    assert err.value.code == ReturnCodes.RET_INVALID_EXPRESSSION


@pytest.mark.parametrize('lic_expr', [[""], ])
def test_fail_on_empty_str_license_expression(parse_simple):
    with pytest.raises(TypeError):
        pass

However, given the fixtures there, at the moment it seems to be more complicated to handle raised exceptions within fixture.

Second thing is more of a typical bug - flict, given a normal string to parse - parses it without complains - while it is not a valid license expression string.

Originally posted by @kkrolczyk in #230 (comment)

@priv-kweihmann
Copy link
Collaborator

priv-kweihmann commented Nov 23, 2022

I thought about this a bit - what the license parser should do is

  • remove the brackets as currently implemented
  • split at AND and OR only
  • replace WITH statements by -with- (compat db should have entries for that, like GPL-2.0-or-later-with-custom-exception - otherwise it will be hard to automatically check compat with others, as exceptions tend to be a bit random in their scope, so I would suggest to add those edge cases manually to the DB)
  • throw an error in case any of the items still has a blank in it

@hesa thoughts?

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