kn0ckn0ck

Как я понял ваши продукты про повышение удобства/эффективности/продуктивности и вы их продаете в среде, где удобство/эффективность/продуктивность не ценится. Подумайте о том, что же вы все-таки продаете, если продажи случились. Проанализируйте реальные причины, по которым уже купили ваши продукты.

Образовательные учреждения - это не бирюзовые организации, прикольные фишки внедрять они сами никогда не станут, пока не будет регламента или приказа на это сверху. А вот инициатором таких внедрений могут стать ИТ-подразделения (в любом крупном ВУЗе такие есть). Вам нужно говорить с аналогом CIO в корпорациях, это кто-то типа зам. проректора по ИТ ВУЗа. Ему нужно показать реальные выгоды от внедрения, тогда он возможно пойдет уговаривать сделать приказ на внедрение этого в учебный процесс.

Сама по себе модель SaaS для большой/неповоротливой организации выглядит сомнительной. Идея SaaS - надо пользуйся, не надо - не плати. Если для внедрения продукта требуются изменения во внутренних бизнес-процессах организации (в учебном процессе, например), то ради какого-то стартапа это делать вряд ли будут. Нужно решение, которое можно поставить и обслуживать своими силами в течение лет 5 - 10. Убедитесь, что ваше решение не требует изменения существующих бизнес-процессов/регламентов/навыков персонала. Либо это другая история.

Большинство образовательных учреждений в РФ государственные и подпадают скорее под категорию социального предпринимательства. Это не сосвем бизнес и скорее всего не для стартапа без серьезных внешних инвестиций. Убедитесь, что ваша бизнес-модель реалистична. Возможно, ВУЗы в большинстве не готовы даже бесплатно использовать ваши продукты, о каком бизнесе тут может идти речь?

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

Не стоит смешивать модульные тесты и интеграционные (или функциональные). Цель модульных тестов проверить работу одного модуля (класса, например). В этом случае все его зависимости мокаются. Целью интеграционных тестов является проверка взаимодействия цепочки модулей (сервисов, с БД и т.п.) друг с другом.

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

То есть правильно было бы сформулировать вопрос таким образом: "какой процент покрытия модульными тестами будет достаточным для моего кода?" Обычно останавливаются где-то на 70-80%

Также очевидно, что 100% работающих модульных тестов не гарантирует работу интеграционных тестов или функциональных. Поэтому необходимо писать и те и другие.

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

Конечно автору курса двойку за объяснение, он его так и не дал :) Другое дело, что скорее всего здесь имелось ввиду форма документирования проверки. Чек-лист - это простая форма проверки: тут есть, там есть, тут нормально, там тоже ничего. Тест-кейсы обычно куда более сложные, объемные и разноплановые, поскольку многие проверки не укладываются в простановку галочек.

Здесь на самом деле два вопроса:
1. на чем написать приложение?
2. продавать его или сделать мир лучше за бесплатно?

ИМХО, проще найти работу на C#, но за хорошее знание C++ могут платить больше, однако нужен опыт. Настольные приложения быстрее и проще писать на C#. Таким образом, для целей быстрее найти работу выгоднее C#

Второй вопрос гораздо сложнее, поскольку извлечение прибыли возможно в обоих вариантах. Важно учитывать следующее:
1. Коммерческий продукт требует гораздо больше трудозатрат на "упаковку" и продажи, часто это упускается. Чтобы продукт покупался нужен сайт, годный контент на нем, трафик (+реклама), удобная установка, схема лицензирования, справка помощи и... поддержка! (да, оперативно отвечать на глупые вопросы пользователей).
2. Бесплатное приложение больше ориентировано на пользователей, которые сами себе его находят, продают, поддерживают и т.п.

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

Риски связанные с коммерческим продуктом:
1. Вложить много сил/денег и не продать ничего (либо несколько экземпляров), либо понять, что такой продукт на самом деле не нужен.
2. Вложить много сил/денег и узнать, что есть бесплатный аналог или его уже сделают за время предпродажной подготовки.
3. Промахнуться с рынком сбыта. А иностранные рынки это еще дополнительная головная боль и расходы.

Риски связанные с open-source:
1. Потеря возможности получить оплату за свое "ноу-хау". Другими словами, не стоит опенсорсить авторские алгоритмы (или трудоемкую реализацию), которые сами по себе имеют ценность и которые сложно повторить. Именно в этом основная ценность ПО.
2. Невозможность извлечь прибыль из своего труда, особенно, когда это занимает много времени. Здесь нужно аккуратно делить на бесплатные и платные фичи. Иначе хорошее дело очень быстро загнется, хоть и бесплатное для пользователей.

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