В чем разница между тестированием «белого ящика» и «черного ящика»?

А, ну вот, опять про эти ваши ящики, блядь! Слушай, давай разберёмся, пока ты не начал путать белое с чёрным, как какой-нибудь дальтоник в тёмной комнате.

Представь себе, блядь, два подхода к разбору полётов твоего свеженаписанного говнокода.

Тестирование "белого ящика" (White-box) Это когда ты, сука, залезаешь внутрь движка, как хирург-извращенец. У тебя есть доступ ко всему: к исходникам, к этим твоим кривым условиям if, к циклам, которые могут зациклиться нахуй. Ты смотришь на код и думаешь: "Ага, щас я тебя, мудень, проверю по всем веткам, чтобы ни одна else не осталась непротестированной, блядь!"

• Смысл: Убедиться, что внутренняя логика не ебёт мозг и работает как часы. Проверить ВСЕ пути, даже те, до которых пользователю, как до Луны.
• Кто этим страдает: Ты сам, разработчик, или твой коллега-автоматизатор, который тоже в теме.
• Примеры: Модульные тесты (unit), интеграционные — вся эта низкоуровневая движуха.

Вот, смотри, пример белого ящика на Python:

def calculate_discount(price, is_member):
    if is_member and price > 100:  # Ветвь 1
        return price * 0.9
    elif is_member:                # Ветвь 2
        return price * 0.95
    else:                          # Ветвь 3
        return price

# Белый ящик: мы ВИДИМ эти три ветки и долбим по каждой!
def test_calculate_discount():
    assert calculate_discount(150, True) == 135   # Бьём по первой ветке
    assert calculate_discount(50, True) == 47.5   # Ловим вторую
    assert calculate_discount(100, False) == 100  # И добиваем третью

Тестирование "чёрного ящика" (Black-box) А это уже, блядь, магия! Ты подходишь к системе как обычный юзер-лох. Ты не знаешь, что там внутри: база данных, микросервисы или гномы с молоточками. Ты знаешь только, что если тыкнуть сюда — должно высраться туда, согласно бумажке под названием "Требования".

• Смысл: Убедиться, что эта штука в принципе работает для пользователя, а не только для твоего продвинутого IDE.
• Кто этим занимается: Тестировщики, аналитики, иногда сами заказчики (и тогда начинается ад, блядь).
• Примеры: Функциональное тестирование, приемочное (UAT), когда заказчик говорит "ой, а можно вот так?".

Пример чёрного ящика для какого-нибудь API:

// Тестировщик видит только интерфейс: "Эй, API, прими логин и пароль, отдай токен!"
// А как ты там внутри пароль хэшируешь — ему похуй, это твои проблемы.
POST /api/login HTTP/1.1
Content-Type: application/json

{"username": "test", "password": "secret"}

// И он ждёт ЧЁТКО ЭТОТ ОТВЕТ:
HTTP/1.1 200 OK
{"token": "some_jwt_token"}
// Всё! Никаких подробностей про "белый ящик", только вход и выход.

Короче, сводка для тех, кто в танке:

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