joha0738

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

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

Что значит ожидаемое поведение? когда ты делишь задачу на подзадачи, у тебя появляются промежуточные данные и состояния, ну как в анекдоте про чайник и программиста, чтобы заварить чай нужно:
* налить воду в чайник
* поставить на базу/печку и включить
* дождаться готовности/выключить
* налить чай
на каждом этапе нужно проверять состояние, например первый пункт - есть ли вода в чайнике, горячая ли она или холодная, полный ли чайник, есть ли у тебя чайник в руках, и т.п.

Тесты создают на основе данных, являющихся нормальными, ненормальными и граничными для тех алгоритмов, что используются в коде. К примеру нет нужды проверять температуру воды в чайнике отдельно на фиксированные значения 10, 20, 30,.. градусов, если в алгоритме заложены естественные их границы - холодная и горячая, вот вокруг этих констант и приходится гулять.

Вот именно эти проверки и есть тесты, которые необходимо автоматизировать.

Степень полноты тестирования вопрос философский, в конечном счете тесты нужны не только для автоматического тестирования и составления отчетности на изменения кода, но и собственно для разработки, разрабатывая тесты ты делаешь код полнее и точнее (например проверяя температуру воды на первом шаге ты добавишь в код условие - если вода горячая, то пропустить ее нагрев), почитай про test-driven development, TDD

p.s. а еще тесты - это способ исследовать неизвестную библиотеку, дело в том что open source реалии таковы, что документации нет от слова совсем, в лучшем случае перед тобой список методов с типами аргументов и пара примеров, все остальное нужно догадываться по логике наименований, здравому смыслу и ковырянии в исходниках. Тесты тут могут быть исключительно как способ изучения этой библиотеки, но не обязательно такие тесты реализовывать в коде, это все же процесс в ручную происходит, но все же, создавать тесты на ответы от чужой библиотеки полезно для длительной поддержки проекта для того, чтобы у тебя были алерты на необычное поведение ее после обновления)

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

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

1) Положите в проект схему базы и тестовые данные в виде sql-файлов, или сделайте утилиту для их загрузки из какого нибудь json/xml/yaml/edn/etc...
2) Напишите файл Readme.md, в котором опишите настройки, где они лежат и как залить схему и тестовые данные. Укажите требования к проекту, как собрать, какие типы баз использовать, какие версии явы и прочее...
3) Попробуйте собрать свой проект без использования среды разработки, только из консоли с использованием maven, gradle или что вы там используете (ant?).
4) Обязательно укажите запускаемый класс с main-методом, ну или укажите его в в файле-сборки
5) Залейте проект на гитхаб и попросите кого нибудь его протестировать
6) Необязательно, но в тесты тоже иногда смотрят. Если они есть, не отказывайте в удовольствии и их в проект пихнуть.

Ява-программисты, они умные, могут и в мавен, и в градл, и в пропертях поковыряться.

1. Правильно спроектированную базу данных потребуется изменять только при изменении логики приложения

2. Пример структуры таблиц под ваше описание:

create table questionnaires (
        id int primary key auto_increment,
  	title varchar(255)
);

create table questios (
        id int primary key auto_increment,
  	questionnaire_id int,
  	title varchar(255),
  	foreign key (questionnaire_id) references questionnaires(id)
);

create table answers (
        id int primary key auto_increment,
  	question_id int,
  	title varchar(255),
  	rigth bool,
  	foreign key (question_id) references questios(id)
);

SQL online fiddle

Добрый день.
Как отметил коллега Developer вопрос действительно обширен.
Ну во-первых, вам нужны сущности User, Role & Privilege (необязательно). У каждого пользователя есть set ролей, каждая из которых содержит set привилегий. Есть роль ADMIN, а также например, USER.

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

Не совсем понятно, как именно вы создаете таблицы (db first || corde first). Для простоты используйте возможности Sping Data JPA.
Что касается вопроса о расширении, то как правило, используют sql скрипты (патчи), которые кладут например, в resources и используют flyway. При перезапуске он применяет нужный sql файл. Также необходимые правки вносят в код сущности.

Для анкеты необходимо создавать несколько таблиц (Для названия анкеты, названия ее вопросов и вариантов ответа) или все это лучше запихнуть в одну таблицу?

Вы можете создать 1 сущность: анкета, которая содержит список вопросов. Список вопросов в свою очередь содержит список ответов. У каждого ответа есть напрмиер, некий флаг, является ли данный ответ верным или нет.
В общем, существуют разные типы тестов и каждый из них отличается. Например, есть тесты, в которых есть правильный ответ. Есть тесты, в которых нет правльных ответов, но у каждого ответа есть балл, который впоследствии суммируется и выдается результат и т.д.

Можно.

Так как кода никакого не предоставлено, то расскажу так же на словах:
Условно говоря, пишете метод, который производит операции и записывает результат в некую переменную. Например, double result
Далее клик на каждой кнопках ( + - * /) триггерит и вызывает метод, который отображает предыдущий результат. Т.е. вышеперечисленные кнопки играют роль кнопки =.
Примерно как-то так...