Рубрика «unit tests»

FYI: this article is an expanded version of my talk at SQA Days #25.

Based on my experience with colleagues, I can state: DB code testing is not a widely spread practice. This can be potentially dangerous. DB logic is written by human beings just like all other «usual» code. So, there can be failures which can cause negative consequences for a product, business or users. Whether these are stored procedures helping backend or it is ETL modifying data in a warehouse — there is always a risk and testing helps to decrease it. I want to tell you what tSQLt is and how it helps us to test DB code.

Testing SQL Server code with tSQLt - 1

Читать полностью »

FYI: эта статья представляет собой дополненную версию моего доклада на SQA Days #25.

Опираясь на свой опыт общения с коллегами, могу утверждать: тестирование кода в БД не является распространённой практикой. Это может нести в себе потенциальную опасность. Логику в БД пишут такие же люди, какие пишут «обычный» код. Следовательно, там так же могут присутствовать ошибки, и они так же могут повлечь за собой негативные последствия для продукта, бизнеса и потребителей. Неважно, идёт ли речь о хранимых процедурах, помогающих бэкенду, или о ETL, преобразующих данные в хранилище — риск есть, и тестирование может его существенно снизить. О том, что такое tSQLt и как оно помогает нам в тестировании кода в SQL Server, я и хочу вам рассказать.

Тестируем SQL Server код с tSQLt - 1

Читать полностью »

Zen of Unit Testing - 1

Ability to write good unit tests is an important feature of any developer. But how to understand that your unit tests are correct? Good unit test is like a good chess game. In our case chessmen are the approaches which we are going to discuss in this post. There is no best chessman in a chess game because everything depends on the positions (and a player). Likewise, in unit testing you don't have to distinguish only one approach. In other words, you should use all approaches together to get the best result. So, if you want to win this game, then welcome under the cut.

Читать полностью »

Сегодня хочу вам быстренько рассказать как тестировать асинхронный код.
Представьте ситуацию, что вам надо загрузить данные из интернета и проверить все ли работает нормально, либо еще какую-нибудь задачу, которая выполняется асинхронно. И как же его протестировать? Что если попробовать так же как и обычный синхронный код?!

    func testAscynFunction() {
        someAsyncFunction()
    }

    func someAsyncFunction() {
        let bg = DispatchQueue.global(qos: .background)
        bg.asyncAfter(deadline: .now() + 5) {
            XCTAssert(false, "Something went wrong")
        }
    }

Такой тест вернет нам положительный результат, так как метод не будет ждать всех наших асинхронных задач.

Для решения такой проблемы в тестах есть одна замечательная вещь: Читать полностью »

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

Держим дизайн системы под контролем, используя изолированное юнит-тестирование - 1

Сегодня мы поговорим о том,

  • Как делать тестирование сложными зависимостями?
  • Как добиться большого тестового покрытия?
  • Как тесты влияют на дизайн?
  • Что делать, когда много логики в базе?
  • Как соблюсти компромисс между дизайном и «не дизайном».

Читать полностью »

Впервые я встретился с юнит тестированием на Java и был рад возможности делать моки на final классы, на статические члены. В это время на .Net нельзя было сделать ничего подобного. Только интерфейсы. Можно безгранично долго рассуждать о том, что если понадобилось делать что-то неестественное, то нужно переписывать реализацию, делать IOC и прочее. Но когда речь идет о наследованном коде, неприспособленном архитектурно к юнит тестированию – возможность менять вещи без переписывания выручает.
Я окончательно забросил Java и ушел в .Net и каждый раз при разговоре о юнит тестах вспоминал, что на Java возможностей больше.
И вот в 2012 студии добавили возможность делать мок любых объектов. Абсолютно любых, даже системных. Под катом перевод статьи из MSDN (переведено только по шимам, т.к. стабы особого интереса не представляют).
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js