Алексей Костюхин

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

Собственно, это нормально и правильно - вы же поменяли сабмодуль? Поменяли.

Следовательно, родительский проект теперь, фактически, использует другую версию сабмодуля.

Следовательно, сабмодуль нужно закоммитить и обновить ссылку у родителя (и тоже закоммитить).

Почти весь embed, и гражданский, и военный, пишется на C.

location /client/dev {
        alias /var/www/site.ru/build;
        try_files $uri /index.html =404;
}

Или

location /client/dev {
        alias /var/www/site.ru/build;
        try_files $uri /client/dev/index.html;
}

нет разницы

https://metanit.com/web/nodejs/10.1.php
https://github.com/expressjs/multer

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

var path = 'public/uploads/file.txt',
buffer = new Buffer("some content\n");

fs.open(path, 'w', function(err, fd) {
    if (err) {
        throw 'error opening file: ' + err;
    }

    fs.write(fd, buffer, 0, buffer.length, null, function(err) {
        if (err) throw 'error writing file: ' + err;
        fs.close(fd, function() {
            console.log('file written');
        })
    });
});

Как читать объяснять?

fs.open(filepath, 'r', function(err, fd) {
    fs.fstat(fd, function(err, stats) {
        var bufferSize=stats.size,
            chunkSize=512,
            buffer=new Buffer(bufferSize),
            bytesRead = 0;

        while (bytesRead < bufferSize) {
            if ((bytesRead + chunkSize) > bufferSize) {
                chunkSize = (bufferSize - bytesRead);
            }
            fs.read(fd, buffer, bytesRead, chunkSize, bytesRead);
            bytesRead += chunkSize;
        }
        console.log(buffer.toString('utf8', 0, bufferSize));
        fs.close(fd);
    });
});

Принимаем по websocket файл с клиента:

// Convert a binary buffer into a "binary" encoded string.
function binaryEncode(buffer) {
  var string = "";
  for (var i = 0, l = buffer.length; i < l; i++) {
    string += String.fromCharCode(buffer[i]);
  }
  return string
}

// Convert a "binary" encoded string into a binary buffer.
function binaryDecode(string) {
  var length = string.length;
  var buffer = new Buffer(length);
  for (var i = 0; i < length; i++) {
    buffer[i] = string.charCodeAt(i);
  }
} 

client.on('stream', function(stream, meta){
  var bufs = [];
  stream.on('data', function(data){
    bufs.push(data);
  });
  stream.on('end', function(){
    var buf = binaryEncode(Buffer.concat(bufs));
    fs.writeFile(__dirname + "/tmp/"+meta.frame+".dat", buf, "binary", function(err) {
      if(err) {
        console.log(err);
      } else {
        console.log("The file was saved!");
      }
    });
  });
}

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

Вся прелесть Heroku в том, что отдел DevOps уже не нужен. Все деплои, форки целого приложения, подключение любого сервиса (базы данных, логирование, мониторинг, рассылка почты и т.д.) делаются в пару кликов. Получается, что вся работа девопсов уже сделана.

base64 --help

MYFILE=$(base64 -w0 <file>)

google://npm parse xml

Да, конечно можно, это более чем реактовский компонент.
Тут единственное что - можно привязки через рефы делать, да класс поменять на компонент с хуками.
Но по факту будет тоже самое.

А по чистоте и оптимизации кода могут быть уже отдельные вопросы.

() => (wraped)

Это будет иметь смысл если в первых скобочках будут какие-то параметры.
То есть вы можете сделать функцию которая будет как-то сконфигурирована, которую можно вызывать передавая wraped.
например

const withBookStoreService = (consProps) => (wraped) => {
  return (props) {
    return (
      <Consumer ...consProps>
        {
          (value) => {
            return (
              <Wraped {...props}
            )
          }
        }
      <Consumer>
    )
  }

Тогда вы можете сделать

const hoc1 = withBookStoreService(props)
const hoc2 = withBookStoreService(otherProps)

const wrappedInHoc1 = hoc1(component)
const wrappedInHoc2 = hoc2(component)

Скорее всего в оригинале это так и было, потом просто упростили до потери смысла. В таком виде как вы привели это конечно излишняя конструкция.

так же можно написать () =>() =>() => (wrapper)