Alexej Simakov

сервер для вас - черный ящик в данном случае. поэтому единственное место где можно проверить реакцию на стимул это клиент. Т.е. вы можете делать только end-to-end тесты. Но без возможности контроллировать сервер, многие сценарии проверить не удастся. Например, если сервер шлет оповещение клиенту за 15 минут до начала события (допустим это напоминалка). Чтобы прокрутить часы вперед и проверить срабатывание и обработку напоминания (напр. если мы заглушили оповещение оно не должно больше приходить) нужен доступ к серверу.
С другой стороны, чтобы спроектировать тест сервер не нужен, тест проектируется в голове, а вот то, что его нельзя будет выполнить без специальных возможностей это нужно донести до заказчика.

Это нормально, другие делают вид что поняли, кивают, а потом выясняется что они не до конца все поняли. Но тогда уже поздно. Лучше сразу дать понять что ты не до конца понимаешь. Переспросить, переформулировать.
Я вообще по жизни угараю с совещаний - всегда такое впечатление что все все поняли - но оказывается что никто ничего до конца не понял, все просто покивали головами чтобы не казаться дураками. Никогда не надо стесняться спрашивать, хоть это и не всегда удобно. Как говорят японцы: "Спросить — стыдно на минуту, а не знать — стыд на всю жизнь"
Не стесняйтесь тормозить разговор. Типа:
- Можно я перескажу своими словами как я это понял.
- Я хотел бы лучше понять для чего это нужно? Какую проблему это решает?
Особенно если вы новичок никто не будет предьявлять к вам завышенных требований, а кто-то даже наборот отметит тягу к знаниям. Нет ничего хуже когда человек до конца не разбираясь делает вид что он шарит и ему все по-плечу (Эффект Даннига-Крюгера).

Есть еще т.н. проблема XY xyproblem.info - обязательно ознакомьтесь. Я однажды с удивлением выяснил, что страдаю этим синдромом. Не обьясняю контекст задачи, а задаю конкретный вопрос. Это ставит людей в тупик, и в этом нет ничего хорошего. Со временем я приучил себя обьяснять проблему так чтобы мне давали развернутый ответ. Главное не бояться перегрузить людей деталями. Они, эти детали, как правило сильно меняют дело.
Вот шаблон с контекстом:
- Я делаю ... у меня есть ... и для того чтобы сделать ... я использую ... . Но если мне нужно ..., например чтобы .... то этот подход не работает. Как можно сделать лучше?

Также я приучил себя всегда стараться дать пример, на примере всегда быстрее и четче доходит. И сразу есть контекст на котором можно проверить ответ. Не жалейте времени составляя хороший пример. Хороший пример всегда можно горизонтально и вертикально расширить, типа:
- А что если у меня этих ... будет N штук.
- А что если у нас нет прямого доступа к .... Ну, например, оно управляется через ...?
Прямо к примеру так и припишите все дополнительные расширяющие вопросы. Перечитайте еще раз. Уберите ненужное. Что-то отвалится само.

Иногда я использую то, что я называю отложенным мышлением (deferred thinking). В том случае если нет времени на обсуждение. Я задаю вопрос, и просто запоминаю ответ, и обдумываю его потом. А человеку говорю "Спасибо за наводку, я еще раз все прокручу в голове. Если мне еще что-то будет не понятно я приду снова, окей?" Обычно никто не отказывает. Главное предупредить что ты возможно придешь еще раз.

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

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

Вообще подумайте, каким образом это условие может возникнуть, что имя у пользователя отсутсвует. (Я думаю - он его стер, он его не задал при создании аккаунта) Но может есть еще какие-то способы.
Тогда это будет просто одним из ожиданий тестов в разделе "изменение данных пользователя" и "создание пользовательского аккаунта"

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

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

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

Вот эскиз того как я при этом думаю:

Вот тут мы получаем это, а потом передаем сюда, а, нет наверное лучше без параметра, тогда в конструктор вот тут. А потом в зависимости от результата .. если значение 1 то .. а если ноль то .. так, я не хочу чтобы у меня тут были условия. Пусть тогда функция сразу делает, то что надо в зависимости от результата. Тогда переименуем функцию, чтобы было ясно как она работает. Так, ага, все красным подчеркнуто - ну да, щас заимплементим и будет конфетка."

И тогда остается наполнить эти функции жизнью.

У меня был даже интересный опыт, я делал заказ на добавление функции во фреймворк. Я им дал код того как я бы использовал эту новую функцию у себя в коде. Им по факту оставалось только заставить мой код работать. На удивление они очень быстро справились, и не перезванивали уточнаяя детали (как это обычно бывало).
T.e. код служил спецификацией. В этом подходе всего два шага:

1. "Я хочу чтобы мой конечный код выглядел вот-так"
   
2. "Волшебник, сделай так, чтобы оно заработало."
   

P.S. Вот еще рекомендую просмотреть (хотя бы часть 2 и 3): Паттерны для масштабируемых JavaScript-приложений