Василий Банников

1. Есть xunit
2. Есть библиотеки с альтернативными ассертами. Например я везде fluentassertions использую
3. Mstest на коре вроде тоже есть.
4. Вместо атрибута ExpectedException лучше использовать аналогичный ассерт:
https://docs.nunit.org/articles/nunit/writing-test...

позволяет удобно работать с XML-файлами и не только

Фу какая гадость. Зачем тебе это в тест-фреймворке???

AssemblyInitialize!

Зачем он тебе?

В случае delete, если корзина отсутствует - вполне может вернуться и 200 код и это будет вполне нормальным поведением, тк идемпотентность.
Так что лучше проверить через get

Какой тип у ProductId? Если это Guid, то смотри какие у него конструкторы есть.
Проще всего через Guid.Parse.

PS:
А DbContext мокать не нужно. Используй вместо этого EF Core inmemory, либо Sqlite с размещением в оперативной памяти.

Будет что-то типа:

var conn = new SqliteConnection("DataSource=:memory:");
var options = new DbContextOptionsBuilder<ApplicationContext>()
   .UseSqlite(conn)
   .Options;

using var dbContext = new ApplicationContext(options);
dbContext.Products.Add(new Product { /*...*/});
dbContext.SaveChanges();

var controller = new CartController(dbContext);
// ...

PPS:
Если ты хочешь тестировать контроллеры - значит ты что-то делаешь не так. Возможны два варианта:

1. Ты наговнокодил и затолкал бизнес-логику в контроллеры.
Если так, то выноси логику в сервисы и делай так, чтобы контроллер зависел от сервисов.

2. Тебе на самом деле нужны интеграционные / api-тесты / e2e-тесты. В таком случае тебе нужно не контроллер конструировать, а поднимать сервер и тестировать при помощи http-запросов. В таком случае следует ещё и по пути полноценную СУБД поднимать, а не мок.

Раз у тебя уже есть готовый список, то вот что можно ответить:

Самое важное, без чего ты вообще никак не сможешь работать:
ASP NET Core, Postgresql
Им нужно уделить больше внимания.
Курсы есть и по тому и по другому, есть и вполне хорошие бесплатные.
Например у Postgrespro есть бесплатный курс (тебя должен интересовать PostgreSQL для разработчика) и книги.

Затем то, что точно пригодится в работе, но что сравнительно быстро можно изучить:

git - ты его не упомянул, но он очень важен. Есть бесплатная книга Pro Git где подробно описаны все его команды + есть немало видео на youtube где в действии показано, как им пользоваться.

SOLID - можно почитать статьи и книгу "Чистая Архитектура". В любом случае от тебя не ждут знаний на уровне архитектора тут.

Unit tests - просто попробуй сам писать тесты на каком-нибудь фреймворке. Например на xUnit.
Ещё можешь почитать книжку Кента Бэка про разработку через тестирование.

Code review - просто почитай пару статей о том, зачем это нужно, и как не быть мудаком-ревьюером, и как принимать обратную связь на ревью.

Методологии разработки - просто ознакомься с теми, какие вообще есть.
Большинство сейчас работают по Scrum или Kanban (либо на чём-то производном от них).
Можешь ещё agile manifesto почитать
Опять же - от тебя тут не ждут знаний уровня менеджера проектов, и тебе не придётся с нуля процесс разработки в команде выстраивать.

Сначала замечания по реализации:

1. Раз уж мы делаем свой аналог List - тогда есть смысл вынести его в библиотеку, а не с Exe.
TargetFramework стоит делать чуть более новым. Сейчас LTS - .NET 6 (но это не так уж и критично)

2. Почему List Только для char реализован? Почему не сделать его обобщённым?

3. Почему List не реализовывает стандартные интерфейсы? Тот же IEnumerable<T> хотябы.

4. PrintForward - явно какой-то лишний метод. Список не должен отвечать за вывод в консоль.

5. Публичный сеттер в Node выглядит как что-то опасное. Так можно изменить Next или Previous - лист изменится, вплоть до изменения количества элементов, но значение Count в самом листе не изменится, от чего всё поломается.

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

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

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

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

Мы так например делали, когда надо было большой и сложный XML перегонять в такой же большой и сложный текстовый или бинарный формат.

Конечно, отдельно ещё в юнитах проверялась конвертация на небольших кусках, но надо было ещё в комплексе всё проверять.

2. Тоже самое только с интеграционным тестированием, может ли оно быть не автоматическим ?

Неавтоматическое интеграционное тестирование - это тоже ручное тестирование :)

С чего начать учить Unit тестирование?

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

Можно ещё почитать книжку

Видел что существует много их, типу Moq, XUnit и тд.

Это инструменты для решения разных задач.
Moq - для создания моковых объектов
XUnit - непосредственно фреймворк для описания и запуска тестов.

отлично обеспечивают регрессионное тестирование?

Юниты кстати не всегда могут это обеспечить.
Вполне обычная ситуация - все функции и классы работают идеально, но в приложении всё ломается, тк кто-то криво зарегал их в ioc, или опечатался в имени

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

нет. Если имеется нормальный фреймворк для тестирования, то написать всю тестовую документацию и протестировать руками будет дольше, чем написать e2e тесты.

ИМХО, юнит-тестами, да и UI-тестами, надо покрывать далеко не всё.

Да