Вопрос: Можно ли параметризовать отображаемое имя тестового примера NUnit при использовании `` Ticked names методов``?


Я тестирую F # и использую NUnit в качестве тестовой библиотеки; Я обнаружил использование двойных обратных тиков, чтобы позволить произвольному наименованию метода сделать мои имена методов еще более удобочитаемыми для человека.

Мне было интересно, правильно или неправильно, если можно параметризовать имена методов при использовании NUnit's TestCaseAttribute для изменения имени метода, например:

[<TestCase("1", 1)>]
[<TestCase("2", 2)>]
let ``Should return #expected when "#input" is supplied`` input expected =
    ...

4


источник


Ответы:


Это может быть не совсем то, что вам нужно, но если вы хотите выйти за рамки модульного тестирования, тогда TickSpec  (структура BDD с использованием F #) имеет приятную функцию, где позволяет писать параметризованные сценарии на основе методов back-tick, которые содержат регулярные выражения в качестве владельцев мест.

Например, в Запись в блоге Фила Трелфорда , он использует это для определения сценария tic-tac-toe:

Scenario: Winning positions
    Given a board layout:
        | 1 | 2 | 3 |
        | O | O | X |
        | O |   |   |
        | X |   | X |
    When a player marks X at <row> <col>
    Then X wins

Examples:
    | row    | col    | 
    | middle | right  |
    | middle | middle |
    | bottom | middle |

Метод, который реализует When предложение сценария определяется в F #, используя что-то вроде этого:

let [<When>] ``a player marks (X|O) at (top|middle|bottom) (left|middle|right)`` 
        (mark:string,row:Row,col:Col) =       
    let y = int row             
    let x = int col        
    Debug.Assert(System.String.IsNullOrEmpty(layout.[y].[x]))
    layout.[y].[x] <- mark  

Это аккуратная вещь, но это может быть чересчур, если вы просто хотите написать простой параметризованный модульный тест. BDD полезна, если вы хотите создавать удобочитаемые спецификации для разных сценариев (и есть и другие люди, читающие их!).


5



Это невозможно.

Основная проблема заключается в том, что для каждого input а также expected вам нужно создать уникальную функцию. Затем вам нужно будет выбрать правильную функцию для вызова (или ваш stacktrace не имеет смысла). В результате это невозможно.

Сказав, что если вы взломали что-то вроде eval (который должен существовать внутри fsi), возможно создать что-то подобное, но это будет очень медленно.


1