Allow users to edit token's value

[satelliteqe]

Allow users to edit token's value

[spoore1]

@elyezer that sounds good to me. More flexible than the original request.

And I completely understand about the priority of the xml imports. I'm definitely interested in that feature as well.

Thanks,.
Scott

[elyezer]

@spoore1 I will check but to maintain same behavior as other fields it would be something like:

:title: TEAM-TC: Feature Name: Running Feature with command option 1

And the title will be TEAM-TC: Feature Name: Running Feature with command option 1. Right now betelgeuse is assuming that the first line is the title, but it should consider the :title: field instead if it is present.

According to the current code it already considers that:

title = test.tokens.get('title', test.name)

Which means if :title: field is present it will use that information instead of the test method name as in Python source code. Let me know if you are able to use that otherwise I will work on fixing it.

Will wait to close this issue until I get the feedback if it is working or not.

[spoore1]

Sorry, I don't think I was clear. I wasn't suggesting replacing :title:, I was suggesting if --title-prefix option is used from the command line add that string before the :title: value from code. something like

if title_prefix:
title = title_prefix + title

So regardless of whether it's using test method name or the ":title:" value from docstring, it would add the prefix to the beginning of title.

Does that make more sense?

[elyezer]

Now it makes sense but I don't think we would add that because imagine if someone wants to have a prefix for description for example that will require a new option, so on and so forth. Since this is based on a specific project need and Betelguese is meant to be more generic as possible that prefix needs to be repeated on each title.

I will continue thinking about this so maybe we can implement some inheritance from a broad context like the class docstring or module docstring but that will require to add that information on the test docstring which may not look good, for example the module test_prefix.py:

"""Module test_prefix.py

:title: Global prefix:
"""

class MyTestCase():
    def test_something(self):
        """My test

        :title: {super} more content goes here
        """"

But that will not avoid the repetition.

Let's keep this issue open and hear from others.

[spoore1]

Your example above would work for me. It would still greatly reduce the line length for Title in each test case. Is that method a possibility?

[elyezer]

@spoore1 I think it is possible, just need to define which should be the markup to tell you want to include the super value and then extend it. I will think on a possibility to adding variable support. With that said, I am not sure about a due date because it would require a good effort to support that. I will update here when I have a plan.

[elyezer]

I've been thinking about this issue and figured out that Betelgeuse user may want to add their business logic when providing the final value for a given token. With that in mind I think if Betelgeuse provides a way to specify a Python module where it can inspect and check for functions like get_<token_name> in order to get information for a given token that will allow users to do whatever they want to do in order to have the final token value.

For example, a new option to betelgeuse command group would be added so a user can specify the Python path for the tokens getter module:

betelgeuse --tokens-getter-module 'my_package.tokens_getter'

The path to module must be available at the Python path so Betelgeuse will be able to import it.

Then an example tokens_getter.py module would be:

"""Tokens getter

Helpers for getting tokens value
"""

def get_title(docstring, tokens, invalid_tokens):
    return u'{prefix} {title}'.format(prefix='MY_PREFIX', title=tokens.get('title'))

The benefits of having that kind of feature is that each Betelgeuse user will have the power of customization and business logic specific to the user's project will be handled by them.

The API for the get_<token_name> functions should be better defined so all the information the user can have is available to them.

[elyezer]

@spoore1 let me know what do you think about the proposal above.

Also I am going to be focusing on releasing the xml-test-case which is the base required feature. I will be able to work on improvements only after I finish the base features for the XML importers, currently, I am not able to define a date because I am depending on bug being fixed on the importers to proceed the Betelgeuse code is already written.

[elyezer]

I've updated the title to match more what this issue will accomplish.

The plan will be to allow Betelgeuse to receive an optional path where it can import some methods (if present) to edit the token's value.

The API will be like described in #94 (comment).

[elyezer]

I am going to close this issue since this functionality is already supported by providing a config file. The config allows to specify functions to help get the field values, with that one using Betelgeuse is able to customize the field values programaticaly.

Check the docs http://betelgeuse.readthedocs.io/en/stable/config.html for more information on how to create your config file.