А что подразумевается под "обычными" приложениями и как вы их тестируете?
А если по теме -- то ничем. Юнит тесты везде одинаковы. End-to-end легко реализовать через dependency injection, rewiring и любую библиотеку тестирования которая придет в голову. Многие фреймворки из под коробки поддерживают e2e.
Системное тестирование и continuous integration тем более не отличается. Его принципы не зависят от платформ реализации.
Единственный момент который может Вас смутить в веб-приложении это потребность постоянной слежки за каналом связи, и другие инструмменты для "ручной" проверки, но это вроде бы очевидные вещи...
Пункт 5, другие хорошие советы. С использованием node можно экстремально быстро и легко поднять data-sync api.
Апи слой на ноде позволит сконцентрироватся на изучении и построении модели и фронтенде, которые в данной задаче -- корневые.
Инструммент нужно выбирать исходя из задачи.
Нет. В свое время решили похожую проблему нотификацией в клиенте.
"Мы обновили версию, убедительно просим очистить кеш браузера для нашего портала"
И линка на пошаговую инструкцию
Та и вообще, нужно делать одну функцию клика и просто при клике изменять состояние ul. Скрыто -- показать, показано -- скрыть. Проверяете значение style.display и меняете.
Так и делаю, просто есть потребность отслеживать попытки хака. По факту -- нужен такой юзкейс: пользователь отправляет код, если все ок -- ему отдает результат, если нет -- ему говорит "ай-яй-яй, плохой мальчик вот такие вещи, а именно: 1, 2, 3 ... 10 у нас делать нельзя, прости".
Станислав Макаров: создаю класс MyIterator в котором и определяю поведение операторов для моей структуры. Наследуюсь от STL итератора с тегом bidirectional_iterator_tag и типом узла.
