Толстый Лорри

Я Студент.

Студент какого учебного заведения?

Шилдта в руки и вперед!

Как мне составить план чтобы добиться нужного мне результата как можно быстрее?

А какой результат вам нужен? Хэлловорд сможете написать уже через час, а нормально что-то писать начать средний человек может через полгода-год.
5-6 часов в день - это очень дофига для изучения. Я бы даже сказал, этого слишком много, ибо поглотить информации можно больше, чем "переварить", в голове образуется стылая плотная масса необработаной информации, которая с разных сторон торчит ключевыми словами. Оптимально - это 3-4 часа (2 на теорию + 1 на эксперименты с кодом) + здоровый сон в 7 часов.

Во-первых, вы куда-то торопитесь? Не стоит, ничего гениального в ближайший год из-под пера не выйдет, это нормально. Сначала учитесь худо-бедно что-то примитивное писать, параллельно изучая API FCL, потом на этой базе делать маленькие тулы. Затем беретесь за серьезную литературу, вроде Рихтера и познаете суть CLR. Знания C/C++ здесь могли бы пригодиться, если вам их будут преподавать. Затем "Банду четырех" и учитесь примитивы собирать в кучу грамотно, используя паттерны разработки. Параллельно осваиваете кучу новых языков и технологий, экспериментируете (без этого есть риск быстро выгореть и забросить программирование). Полезно устроиться и где-то поработать некоторое время, попилить опенсорс. Ментор - это здорово, но не обязательно. Остерегайтесь платных курсов, любите книжки.

И, главное, если действительно хотите научиться хорошо программировать, тогда не ограничивайте себя Unity (где C# - это язык скриптов, наравне с JavaScript), оттачивайте знания, копайте глубже фреймворков, интересуйтесь IT, учитесь решать реальные проблемы. Ведь это не самая плохая профессия, которая сможет сделать вам будущее.

Обычно приложения делят на три слоя:

• Data Access Layer
  
• Business Logic (Domain models)
  
• UI (Web).
  

BL независим, DAL зависит от BL, UI зависит от DAL и BL (ибо там располагается интерфейсы биндятся на реальные классы).

Если мы рассматриваем классическую схему доступа к данным через репозитории, то:

BL содержит: доменные модели, интерфейсы для репозиториев, сервисы (интерфейсы и реализации, которые работают с репозиториями).
DAL содержит: реализации интерфейсов репозиториев (из BL), т.е. работу с DB, DbContext (от EF) и прочую конкретику о том, откуда и каким образом извлекаются данные.
UI (для ASP.NET MVC) содержит: собственно веб-проект с котроллерами *Controller.cs (Controllers), вьюшками *.cshtml (Views), вью-модели *.cs (Models, те специфические модели, которыми типизируются вьюхи, они могут отличаться от доменных (маппиться с них в контроллере), например, содержать объект с данными пагинации).

Также UI сожержит корень внедрения зависимостей, где связываются между собой интерфейсы и их реализации, например, интерфейсы репозиториев из BL и реализации (заточенные на работу с БД) из DAL.

Пример реализации.

ЗЫ Азы такой архитектуры применительно к ASP.NET MVC есть в замечательной книжке Фримана.

Selenium - на базе обычных юнит-тестов, с ассертами ("сколько пальцев видишь?", "на месте ли кнопка?"). Они медленные, поэтому гонять оптимально ночью, вместе с интеграционными (API, сложные сценарии с данными). Они интеграционные, поэтому покрывать нужно реальные сценарии, т.е. функциональные блоки. У нас, например, тестировщики пишут тест-кейсы (текст вида: "Пойди туда - получишь то."), а по ним программируются автотесты, т.е. точно так, как бы проверял человек. Неплохо бы помимо логов при падении делать скриншоты.
Чем больше покрытие - тем лучше, хотя нужно как-то балансировать, чтобы не чинить их 50% времени от разработки новой фичи =)

Юнит тесты гонять каждый коммит (в маленьком проекте можно руками перед коммитом, а в большом - силами CI после каждого коммита).

На разных логических уровнях можно (и нужно) делать re-throw более общих типов исключений (с ссылкой на оригинал внутри), если нет возможности их обработать на месте. Например, TooLongNameException и NegativePriceException где-то выше станут ModelValidationException, т.е. там вам достаточно знать, что модель кривая, вне зависимости от того, по какой причине это произошло.

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

Зачем "размещать в интернете" тесты? Обычно тестами заведует CI, который лежит там, где пакеты собираются (с целью проверить, что очередной коммит ничего не сломал по "эффекту бабочки").

Но, так или иначе, если сайт публичен, то размещаться тестовый проект может где угодно и представлять из себя что угодно, хоть консольное приложение (никакой ASP.NET вам не нужен, ибо Selenium WebDriver управляет браузером, а не самим приложением). Но чтобы автоматизировать инфраструктуру, удобнее пользоваться специальным тестовым типом проекта.

Потому что \символ считается escape-последовательностью (как \t, \n, \a и прочие).
Их надо либо каждый раз экранировать еще одним обратным слэшем, либо ставить символ @ перед литералом.

Недавно в это погружался)

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

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

Вместо ArrayListнеобходимо использовать типизированный динамический массивList<string>.

public void Click_OpenFile()
{
    string fileName = form1.OpenFie();

    IList<string[]> aL = ParseFile(fileName);

    foreach (var line in aL)
    {
        // Снова собираем токены в строки
        MessageBox.Show(string.Join(" ", line));
    }
}

// Читаем файл и построчно парсим его
private IList<string[]> ParseFile(string fileName)
{
    if (string.IsNullOrEmpty(fileName))
    {
        throw new ArgumentNullException(nameof(fileName));
    }
    if (!File.Exists(fileName))
    {
        throw new ArgumentException($"There is no file {fileName}!");
    }

    string[] fileContent = File.ReadAllLines(result);
    var aL = new List<string[]>(fileContent.Length);
    foreach (var line in fileContent)
    {
        aL.Add(ParseString(line));
    }
    return aL;
}

// Разбиваем строки на токены
private string[] ParseString(string s)
{
    const char delimiter = '|';
    return s.Split(delimiter);
}