Григорий Васильков

Все, нашел решение: event.target https://developer.mozilla.org/ru/docs/Web/API/Even...

краткий ответ: чем длиннее пароль, тем тяжелее(дольше по времени ломать) взломать/подобрать.
т.е. пароль fGyr[1 взломают быстрее, чем 1111111111111111 (16 символов) оригинал
п.с. это если касается "грубой силы" - методом подбора (к примеру в hydra)

п.с.с. а так, если данные передаются не по защищённой связи (к примеру через протокол http, а не https) - то не важно какой пароль, при MITM - его увидят целиком и полностью

или нас, рядовых пользователей, взламывать не станут

цель взлома далеко не всегда является корыстной. Иногда это "развлечение" или даже "тренировка", и кто будет "объектом" не важно (будь то пользователь ВК или почта, или худенький интернет-магазин)

п.с.с.с. использовать 1111111111111111 конечно не стоит, но хотябы так: 1111111111111111_ms

Можно сделать что-нибудь в таком роде:

const stream = require('stream');
const fs = require('fs');

class PercentWatcher extends stream.Duplex {
  constructor(fd) {
    super();
    this.size = fs.fstatSync(fd).size;
    this.handled = 0;
  }
  _read() {}
  _write(chunk, encoding, callback) {
    this.push(chunk);
    this.handled += chunk.length;
    console.log(`\n\n${Math.round(this.handled / this.size * 100)}%\n\n`);
    callback();
  }
}

const fd = fs.openSync('file.txt', 'r');

fs.createReadStream(null, {fd}).pipe(new PercentWatcher(fd)).pipe(process.stdout);

$A = array_udiff($A, $B, function($a, $b) { return $a['id'] - $b['id'] });

Тесты тестам рознь. Они бывают очень разные.
Все зависит от того, что именно Вы хотите протестировать.
Могут быть тесты производительности. Они проверяют что скорость выполнения кода/приложения/запроса удовлетворяет определенному значению.
Могут быть нагрузочные тесты. Они проверяют что приложение/система держит определенные нагрузки.
Могут быть тесты, которые проверяют систему на предмет соответствия определенным стандартам безопасности (PCI compliance check, к примеру).
В принципе, тесты могут тестировать любой интересующий Вас аспект/метрику кода/приложения/чего-угодно.
Чаще всего тесты пишут, чтобы проверить правильность работы заложенной в приложение бизнес-логики.

Все выше упомянутые случаи имею общую черту - какие-либо ожидания, которые подтверждаются, или не подтверждаются тестами.
Соответственно тесты, как таковые, непосредственно связаны с понятием спецификации кода/приложения/модуля/чего-угодно. Собственно, в BDD (behavior-driven development) тесты часто так и называют - spec (спеки).

Идея проста и никаких тайн не содержит:
Вы пишете спецификацию, а тесты доказывают что приложение соответствует спецификации.
Эта идея применяется на любом уровне от самых низкоуровневых модулей, до высокоуровневых частей системы, и самой системы в целом.

Ваша задача не "повалить систему REST api", а удостовериться, что она работает ожидаемым и требуемым образом (что делать должна, и чего не должна). Именно подобные требования и нужно вносить в спецификацию.

Вот очень упрощенная спецификация для Вашего примера:

Допустим если rest_api на вход примет json файл

1. Если на вход ничего не подано, rest_api должен вернуть ошибку 1 (отсутствует тело запроса).
2. Если на вход подан не JSON, rest_api должен вернуть ошибку 2 (некорректный запрос).
3. Если структура JSON не содержит всех необходимых параметров, rest_api должен вернуть ошибку 3 (некорректные параметры).
4. Если передан валидный запрос, rest_api должен вернуть результат в нужном формате.
5. Если передан валидный запрос повторно, rest_api должен вернуть ошибку 4 (файл уже обработан).
Соотвественно, тесты проверяют выполняется ли каждый пункт спецификации.

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

P.S. Разработка программного обеспечения - самая открытая и прозрачная современная профессия. Ни в какой другой области я не встречал аналогов дотягивающих до open source движения, и такого громадного кол-ва докладов/статей в свободном доступе, где люди охотно делятся опытом и понимаем, такого кол-ва обучающих площадок, такого рвения помогать друг другу становиться лучше в профессиональном плане.
Потому, в следующий раз, прежде чем говорить о "средствах манипуляции" и "пруф-линщиках", откройте глаза, зайдите на тот же Github, где можно вот-так просто взять и посмотреть "как оно делается", не поленитесь почитать "пруф-линки", где тема фундаментально разжевана по полочкам, послушать доклады с конференций. Вам все сообщество ставит большую такую миску с кашей под нос - бери и ешь. Если Вы хотите, чтобы Вам рот открыли, ложку в рот положили, и ещё и челюстью подвигали, - так это делают в детском саду воспитатели.

Чем больше тестов, тем лучше.
Тесты не гарантируют корректность кода и идей.
Нормальный тест это "тест черной коробки" - мы не знаем как она реализуется, но мы может проверить как она реагирует на воздействия из вне.
Если мы залезли в черную коробку и копаемся внутри, то ранее написанные тесты дают некоторую гарантию, что мы ничего не поломали.

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