Можно ли тестировать тесты?

Я хочу сделать инструмент, который проверяет различные упражнения. Одно упражнение - это единичное тестирование. Поэтому мне нужно проверить, являются ли тесты, которые сделаны учеником, хорошими тестами. Так, например, учащийся имеет следующий код:

export class HelloWorld {
  public static showHello(): string {
    return 'Hello World!'
  }
}

Следуя шуткам:

import { HelloWorld } from '..'

describe(Hello World exercise, () => {
  test('Check function is defined', () => {
    expect(HelloWorld.showHello()).toBeDefined();
  });

  test('Empty input results in Hello World!', () => {
    expect(HelloWorld.showHello()).toBe('Hello World!');
  });
});

Как я могу проверить, что студент действительно тестировал эти два теста? Я думал о

export const firstTest = test()...

И затем проверьте, проверяет ли firstTest правильную вещь. Но недостатком является то, что вы должны экспортировать каждый тест для этого решения.

Всего 1 ответ


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

Однако есть несколько эвристик, которые вы можете использовать. Я предлагаю использовать комбинацию первых трех из этих методов.

  1. Определите открытый интерфейс, который ваши ученики должны реализовать и написать тесты для этого открытого интерфейса. Это напрямую не проверяет тесты ваших учеников, но если какие-либо из ваших тестов терпят неудачу, они не пишут достаточные (качественные) тесты. Эти тесты должны быть легкими и очевидными для ваших учеников.
  2. Используйте инструмент покрытия кода, такой как istanbul . Это не проверяет качество тестов напрямую, но это дает вам уверенность в том, что тесты на самом деле касаются кода.
  3. Этот метод вдохновлен (а не на реализацию) методикой, которую я недавно открыл, называемой «Adversarial Gamedays». Для этого метода вы бы случайно сломали код ученика в нескольких местах, давайте просто скажем 10, и пусть код запустится. Скорее всего, тесты не поймут все ошибки, которые вы сделали, но они должны поймать x%, где x - допустимое покрытие кода, которое вы определили. Ошибки должны быть достаточно распространены по всей программе, чтобы не воспользоваться одним недостатком. Это проверяет количество и качество.
  4. Визуальный осмотр и / или ручное тестирование. Этот метод подвержен ошибкам и требует много времени. Если у вас нет ТП, это, вероятно, не является жизнеспособным вариантом. Однако, если вы потратите достаточно времени на этот метод, он является самым тщательным и наименее предвзятым.

Как я уже сказал, комбинация первых 3 вариантов была бы оптимальной. Например, предоставите публичный интерфейс для системы, запустите инструменты покрытия кода и произвольно разбейте их на частную реализацию каждого учащегося.


Есть идеи?

10000