Некритические unittest отказы

Question

Некритические unittest отказы

К сожалению для всех ответов, данных другими людьми, Вы не можете DELETE и SELECT от данной таблицы в том же запросе.

DELETE FROM mytable WHERE id NOT IN (SELECT MAX(id) FROM mytable);

ERROR 1093 (HY000): You can't specify target table 'mytable' for update 
in FROM clause

, И при этом MySQL не может поддерживать LIMIT в подзапросе. Это ограничения MySQL.

DELETE FROM mytable WHERE id NOT IN 
  (SELECT id FROM mytable ORDER BY id DESC LIMIT 1);

ERROR 1235 (42000): This version of MySQL doesn't yet support 
'LIMIT & IN/ALL/ANY/SOME subquery'

лучший ответ, который я могу придумать, должен сделать это на двух этапах:

SELECT id FROM mytable ORDER BY id DESC LIMIT n;

Собирают идентификатор и превращают их в разделенную от запятой строку:

DELETE FROM mytable WHERE id NOT IN ( ...comma-separated string... );

(Обычно интерполяция отдельного от запятой списка в SQL-оператор представляет некоторый риск Внедрения SQL, но в этом случае значения не прибывают из недоверяемого источника, они, как известно, являются значениями идентификаторов от самой базы данных.)

примечание: , Хотя это не сделало задания в единственный запрос, иногда более простое, get-it-done решение является самым эффективным.

5

python unit-testing

задан Denilson Sá Maia 10 September 2009 в 17:11

9 ответов

Другие вопросы по тегам:

python unit-testing

Похожие вопросы:

score 8 · Answer 1

С практической точки зрения я бы, вероятно, использовал операторы печати, чтобы указать на ошибку в этом случае. Более правильным решением является использование предупреждений:

http://docs.python.org/library/warnings.html

Однако вы можете использовать средство ведения журнала для создания более подробной записи результатов вашего теста ( т.е. настройте ошибки класса "B" на запись предупреждений в журналы).

http://docs.python.org/library/logging.html

Изменить:

В Django это делается следующим образом. что у нас есть некоторые тесты, которые мы ожидаем провалить, и у нас есть другие, которые мы пропускаем в зависимости от окружающей среды. Поскольку в целом мы можем предсказать, ДОЛЖЕН ли тест завершиться неудачей или пройти (т. Е. Если мы не можем импортировать определенный модуль, система его не имеет, и поэтому тест не будет работать), мы можем разумно пропустить неудачные тесты. Это означает, что мы по-прежнему выполняем все пройденные тесты и не имеем тестов, которые «могли бы» пройти. Модульные тесты наиболее полезны, когда они делают что-то предсказуемо, и возможность определить, ДОЛЖЕН ли пройти тест до того, как мы его запустим, делает это возможным.

и нет тестов, которые "могли бы" пройти. Модульные тесты наиболее полезны, когда они делают что-то предсказуемо, и возможность определить, ДОЛЖЕН ли пройти тест до того, как мы его запустим, делает это возможным.

score 4 · Answer 2

Утверждения в модульных тестах являются двоичными: они будут работать или не будут работать, промежуточных результатов нет.

Учитывая, что для создания этих «некритических» тестов вы не должны использовать утверждения, когда вы не хотите, чтобы тесты провалились. Вы должны делать это осторожно, чтобы не поставить под угрозу «полезность» теста.

Мой совет по отношению к вашему примеру OCR состоит в том, что вы должны использовать что-то для записи успешности в коде вашего теста, а затем создать одно утверждение вроде: " assert success_rate> 8,5 ", и это должно дать желаемый эффект.

score 3 · Answer 3

Я не совсем уверен, как работает unittest, но в большинстве фреймворков модульного тестирования есть что-то вроде категорий. Я полагаю, вы могли бы просто классифицировать такие тесты, отметить их как игнорируемые, а затем запускать их только тогда, когда они вам интересны. Но по опыту я знаю, что игнорируемые тесты очень быстро становятся ... просто игнорируемыми тестами, которые никто никогда не запускает и, следовательно, является пустой тратой времени и энергии на их написание.

Я советую вашему приложению делать или не делать, не пытайтесь.

score 1 · Answer 4

Есть некоторые тестовые системы, которые позволяют выводить предупреждения, а не сбои, но test_unit не входит в их число (я не не знаю, какие из них делают, навскидку), если вы не хотите его расширить (что возможно).

Вы можете сделать тесты так, чтобы они регистрировали предупреждения, а не терпели неудачу.

Другой способ справиться с этим - выделить тесты и запускать их только для получения отчетов о прохождении / отказе и не иметь никаких зависимостей сборки (это зависит от вашей настройки сборки).

score 0 · Answer 5

Another possibility is to create a "B" branch (you ARE using some sort of version control, right?) and have your unit tests for "B" in there. That way, you keep your release version's unit tests clean (Look, all dots!), but still have tests for B. If you're using a modern version control system like git or mercurial (I'm partial to mercurial), branching/cloning and merging are trivial operations, so that's what I'd recommend.

However, I think you're using tests for something they're not meant to do. The real question is "How important to you is it that 'B' works?" Because your test suite should only have tests in it that you care whether they pass or fail. Tests that, if they fail, it means the code is broken. That's why I suggested only testing "B" in the "B" branch, since that would be the branch where you are developing the "B" feature.

You could test using logger or print commands, if you like. But if you don't care enough that it's broken to have it flagged in your unit tests, I'd seriously question whether you care enough to test it at all. Besides, that adds needless complexity (extra variables to set debug level, multiple testing vectors that are completely independent of each other yet operate within the same space, causing potential collisions and errors, etc, etc). Unless you're developing a "Hello, World!" app, I suspect your problem set is complicated enough without adding additional, unnecessary complications.

score 3 · Answer 6

From unittest documentation which you link:

Instead of unittest.main(), there are other ways to run the tests with a finer level of control, less terse output, and no requirement to be run from the command line. For example, the last two lines may be replaced with:
suite = unittest.TestLoader().loadTestsFromTestCase(TestSequenceFunctions)
unittest.TextTestRunner(verbosity=2).run(suite)

In your case, you can create separate TestSuite instances for the criticial and non-critical tests. You could control which suite is passed to the test runner with a command line argument. Test suites can also contain other test suites so you can create big hierarchies if you want.

score 0 · Answer 7

Взгляните на Нос: http://somethingaboutorange.com/mrl/projects/nose/0.11.1/

Существует множество параметров командной строки для выбора тестов для запуска, и вы можете сохранить существующие модульные тесты.

score -1 · Answer 8

Вы можете написать свой тест, чтобы он учитывал процент успешных попыток. С помощью OCR вы можете набросать код 1000 изображений и потребовать, чтобы 95% были успешными.

Если ваша программа должна работать с типом A, тогда, если это не удается, тест не проходит. Если работа с B не требуется, какая польза от проведения такого теста?

score 2 · Answer 9

Спасибо за отличные ответы. Ни один единственный ответ не был действительно полным, поэтому я пишу здесь комбинацию всех ответов, которые мне помогли . Если вам нравится этот ответ, проголосуйте за людей, ответственных за это.

Выводы

Модульные тесты (или, по крайней мере, модульные тесты в модуле unittest ) являются бинарными. Как Гильерме Чапевски говорит : они будут работать или потерпят неудачу, промежуточного срока нет.

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

Итак, модульные тесты мне не подходят, если я m пытается улучшить алгоритм или реализацию, потому что модульные тесты не могут сказать мне, насколько лучше одна версия по сравнению с другой (предположим, что обе они реализованы правильно, тогда обе пройдут все модульные тесты).

My Окончательное решение

Мое окончательное решение основано на идее Райбера и коде, показанном в ответе wcoenen . Я в основном расширяю стандартный TextTestRunner и делаю его менее подробным. Затем мой основной код вызывает два тестовых набора: критический, использующий стандартный TextTestRunner , и некритический, с моей собственной, менее подробной версией.

class _TerseTextTestResult(unittest._TextTestResult):
    def printErrorList(self, flavour, errors):
        for test, err in errors:
            #self.stream.writeln(self.separator1)
            self.stream.writeln("%s: %s" % (flavour,self.getDescription(test)))
            #self.stream.writeln(self.separator2)
            #self.stream.writeln("%s" % err)


class TerseTextTestRunner(unittest.TextTestRunner):
    def _makeResult(self):
        return _TerseTextTestResult(self.stream, self.descriptions, self.verbosity)


if __name__ == '__main__':
    sys.stderr.write("Running non-critical tests:\n")
    non_critical_suite = unittest.TestLoader().loadTestsFromTestCase(TestSomethingNonCritical)
    TerseTextTestRunner(verbosity=1).run(non_critical_suite)

    sys.stderr.write("\n")

    sys.stderr.write("Running CRITICAL tests:\n")
    suite = unittest.TestLoader().loadTestsFromTestCase(TestEverythingImportant)
    unittest.TextTestRunner(verbosity=1).run(suite)

Возможные улучшения

Он все еще должен Было бы полезно узнать, существует ли какая-либо среда тестирования с небинарными тестами, например , предложенная Кэти Ван Стоун . Наверное, я выиграл '