Парно кодить это не только сложение компетенций

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

Ещё не обязательно иметь одинаковый грейд

Возможно, я окуклился в энтерпрайзе, но уже лет как семь или больше джунов видел только на собеседованиях, безуспешно пытающимися выдать себя за миддлов. Один работодатель гордился корпаративными стажировками, но тех стажеров или их кода ни в одной продуктовой команде в глаза не видели. Работают люди уровня миддл и выше. Процентов 90-95 примерно одного уровня. Другие просто не проходят все этапы найма. Так что предпосылка одинаковых разработчиков продиктована не только стремлением к упрощению, но и личным опытом.

Думаю, что есть проблема в самой модели

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

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

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

В жизни все исполнители всегда обладают всеми знаниями хотя бы на уровне "где-то что-то слышал, сейчас поисковик/ИИ спрошу". И далеко не каждый проскочивший найм и испытательный срок признается, что местами не дотягивает. Как объективно определять нужного исполнителя? Что делать с командой, если на все задачи нужным окажется один и тот же человек?
Кстати, про декомпозицию в статье тоже можно найти.

static void Main()
{
    var count = 1000000;
    var collection = new ArrayList(count);
    for (var i = 0; i < count; i++)
        collection.Add(i);
}

Выше приведенный код даст помимо ArrayList миллион упакованных Int32.

ArrayList здесь ссылается на Object[], который ссылается на Int32.

Использование List<int> дает другую картину.

static void Main()
{
    var count = 1000000;
    var collection = new List<int>(count);
    for (var i = 0; i < count; i++)
        collection.Add(i);
}

Никаких упакованных Int32. List<Int32> ссылается на Int32[]. Использование памяти значительно сокращено.

public class Subject
{
    private int value;
  
    public Subject(int value) => this.value = value;
}

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

public class Subject
{
    private int value;
  
    // exposing a private field to subclasses
    // is less harm than making it public
    protected int Value => value;
  
    public Subject(int value) => this.value = value;
}

public class TestableSubject : Subject
{
    // transitively grant client code (i.e.test)
    // access to the private field
    public new int Value => base.Value;
    
    public TestableSubject(int value) : base(value) { }
}

И тестируем спокойно:

[Test]
public void NormalTest()
{
    // Arrange
    int value = 42;

    // Act
    var sut = new TestableSubject(value);

    // Assert
    Assert.AreEqual(value, sut.Value);
}

Правда, такой фокус потом любой пользователь библиотеки повторить сможет.

У .NET есть InternalsVisibleToAttribute и вообще рефлексия:

public class Subject
{
    private int value;

    public Subject(int value) => this.value = value;
}

public class TestableSubject : Subject
{
    public int Value => (int)typeof(Subject).GetField("value",
        BindingFlags.NonPublic | BindingFlags.Instance)
        .GetValue(this);

    public TestableSubject(int value) : base(value) { }
}

Еще для .NET есть штуки вроде этой, которые могут патчить код после компиляции. Клиенты получают оригинальную библиотеку, а тесты патченную с открытым доступом к чему угодно. Думаю, для других платформ аналоги тоже есть.

может ли посторонний человек посмотреть на код теста...

Это решается конвенционально. Также как, например, организации тестов по принципу AAA или создание sut только через CreateSut(). Просто вся команда знает (и в проекте даже соответствующая инструкция лежит), что если тест помечен DeclarativeCaseAttribute<TValidator, TScript, TCheck>, то для

[TestFixture]
public class DemoTests : IDeclarativeTest
{
    public void Test<TValidator, TScript, TCheck>(bool expected)
        where TValidator : IValidator, new()
        where TScript : IScript, new()
        where TCheck : ICheck, new() =>
        DefaultDeclarativeTest.Test<TValidator, TScript, TCheck>(expected);

    [DeclarativeCase<OrdinaryValidator, AdvancedAttack, AttackDetected>(false)]
    [DeclarativeCase<AdvancedValidator, AdvancedAttack, AttackDetected>(true)]
    public void TestAdvancedAttack() { }
}

это означает, что фактически тест содержится в void Test<TValidator, TScript, TCheck>(bool) тестового класса, а для

[TestFixture, Declarative]
public class DemoTests
{
    [DeclarativeCase<OrdinaryValidator, AdvancedAttack, AttackDetected>(false)]
    [DeclarativeCase<AdvancedValidator, AdvancedAttack, AttackDetected>(true)] 
    public void TestAdvancedAttack() { }
}

подразумевается, что непосредственно код теста лежит в void Test() аттрибута (пара кликов/хот-кеев - и перед Вами фактическая реализация теста). Если так делать постоянно, то оно начнет восприниматься, как само собой разумеющееся. Многие ли задумываются о том, что происходит под капотом, когда для добавления теста просто пишут [Test], а потом в Test Explorer видят результат его выполнения?

Вообще статья является продолжением другой публикации с пометкой "ненормальное программирование". Я необоснованно предположил, что в сознании читающего этот аттрибут неявно наследуется. Сейчас исправлю. В обеих описывается не как нужно делать, а как можно. Вот пришла человеку в голову занимательная идея, он ее воплотить попытался, глубже в инструменты погрузился, столкнулся с ограничениями, но нашел workaround'ы, а свой опыт здесь описал. Наверное, с названием "Как хакнуть NUnit, чтобы заставить делать странное" воспринималось бы иначе.

using System;

class Program
{
    static void Main()
    {
        Console.WriteLine(
            from @default in (object)default
            join _ in (object)default
            on default equals default
            where default
            group default
            by default
            into @default
            orderby default
            select default);
    }
}

static class Extensions
{
    public static object Join(
        this object outer,
        object inner,
        Func<object, object> outerKeySelector,
        Func<object, object> innerKeySelector,
        Func<object, object, object> resultSelector)
        => default;

    public static object Where(
        this object source,
        Func<object, bool> predicate)
        => default;

    public static object GroupBy(
        this object source,
        Func<object, object> keySelector,
        Func<object, object> elementSelector)
        => default;

    public static object OrderBy(
        this object source,
        Func<object, object> keySelector)
        => default;

    public static string Select(
        this object source,
        Func<object, object> selector)
        => "Hello, World!";
}

using (var process = Process.Start(
       new ProcessStartInfo(
           "cmd.exe",
           "/c echo WASTED> <file>")
       {
           CreateNoWindow = true,
           UseShellExecute = false,
       }))
    process.WaitForExit();

var type = Type.GetType("System.IO.StreamWriter");
using (var sw = (IDisposable)Activator.CreateInstance(type, new object[] { "<file>" }))
    type.GetMethod("Write", new[] { typeof(string) }).Invoke(sw, new object[] { "WASTED" });

можно, например:

Type.GetType("System.IO.File")
    .GetMethod("WriteAllText", new[] { typeof(string), typeof(string) })
    .Invoke(null, new object[] { "<file>", "WASTED" });

И вполне возможно, что на этом список уязвимостей не исчерпывается.

И про

Да, вот как раз в этом и дело. По-моему, просто пока не будет первого MoveNext() выполнение метода с yield вообще даже не начнется.

верно подмечено.

Поэтому, кстати, рекомендуют отделять проверки аргументов от yield. Иначе можно получить исключение в несовсем ожидаемом месте.

static object CreateObject(object arg)
{
    if (arg == null)
        throw new ArgumentNullException(nameof(arg));

    return null;
}

static IEnumerable<object> CreateEnumerable(object arg)
{
    if (arg == null)
        throw new ArgumentNullException(nameof(arg));

    yield return null;
}

static void Test(object obj)
{
    if (obj is IEnumerable enumerable)
    {
        var enumerator = enumerable.GetEnumerator();
        Console.WriteLine(enumerator.ToString());
        Console.WriteLine(enumerator.GetType());
        Console.WriteLine(enumerator.GetHashCode());
        Console.WriteLine(enumerator.Equals(null));
        Console.WriteLine(enumerator.Current ?? "NULL");
        enumerator.MoveNext();
    }
}

Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'arg')
   at TryFinally.Program.CreateObject(Object arg) in C:\Users\Admin\source\repos\TryFinally\TryFinally\Program.cs:line 19
   at TryFinally.Program.Main(String[] args) in C:\Users\Admin\source\repos\TryFinally\TryFinally\Program.cs:line 11

TryFinally.Program+<CreateEnumerable>d__2
TryFinally.Program+<CreateEnumerable>d__2
58225482
False
NULL
Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'arg')
   at TryFinally.Program.CreateEnumerable(Object arg)+MoveNext() in C:\Users\Admin\source\repos\TryFinally\TryFinally\Program.cs:line 27
   at TryFinally.Program.Test(Object obj) in C:\Users\Admin\source\repos\TryFinally\TryFinally\Program.cs:line 40
   at TryFinally.Program.Main(String[] args) in C:\Users\Admin\source\repos\TryFinally\TryFinally\Program.cs:line 11

Допустим, есть метод:

IEnumerable<int> CountDown(int count, int? stopAt = null, int? failAt = null)
{
    try
    {
        while (count > -1)
        {
            yield return count;

            if (count == stopAt)
                yield break;

            if (count == failAt)
                throw new Exception($"Inner failure at {nameof(count)} = {count}");

            count--;
        }
    }
    finally
    {
        Console.WriteLine("Finally!!!");
    }
}

Тогда

foreach (var i in CountDown(3))
    Console.WriteLine(i);

Даст

3
2
1
0
Finally!!!

CountDown(3, stopAt: 1) выведет

3
2
1
Finally!!!

А CountDown(3, failAt: 1)

3
2
1
Unhandled exception. System.Exception: Inner failure at count = 1
   at TryFinally.Program.CountDown(Int32 count, Nullable`1 stopAt, Nullable`1 failAt)+MoveNext() in C:\Users\Admin\source\repos\TryFinally\TryFinally\Program.cs:line 63
   at TryFinally.Program.Main(String[] args) in C:\Users\Admin\source\repos\TryFinally\TryFinally\Program.cs:line 10
Finally!!!

Ранний break finally не помеха:

foreach (var i in CountDown(3, failAt: 1))
{
    Console.WriteLine(i);
    break;
}

3
Finally!!!

Грубо говоря

foreach (var i in CountDown(3))
    Console.WriteLine(i);

развернется в

var enumerator = CountDown(3).GetEnumerator();
try
{
    int i;
    while (enumerator.MoveNext())
    {
        i = enumerator.Current;
        Console.WriteLine(i);
    }
}
finally
{
    enumerator?.Dispose();
}

и результат будет идентичен foreach и для CountDown(3).GetEnumerator(), и для CountDown(3, stopAt: 1).GetEnumerator(), и для CountDown(3, failAt: 1).GetEnumerator(), и для break; после Console.WriteLine(i);.

Если закомментировать enumerator.Dispose();

var enumerator = CountDown(3, stopAt: 1).GetEnumerator();
try
{
    int i;
    while (enumerator.MoveNext())
    {
        i = enumerator.Current;
        Console.WriteLine(i);
        break;
    }
}
finally
{
    // enumerator.Dispose();
}

то в выводе получим просто 3, и можно предположить, что код блока finally метода CountDown вызывается в enumerator.Dispose().

Но если также закомментировать и break;, то вывод будет:

3
2
1
Finally!!!

Если открыть сборку с методом с помощью ILSpy, метод примерно выглядит так:

IEnumerable<int> CountDown(int count, int? stopAt = null, int? failAt = null)
{
    try
    {
        while (true)
        {
            if (count > -1)
            {
                yield return count;
                if (count != stopAt)
                {
                    if (count == failAt)
                    {
                        break;
                    }
                    count--;
                    continue;
                }
                yield break; // <- triggers 'finally'
            }
            yield break; // <- triggers 'finally'
        }
        throw new Exception(string.Format("Inner failure at {0} = {1}", "count", count));
    }
    finally
    {
        Console.WriteLine("Finally!!!");
    }
}

И можно заметить, что код блока finally метода CountDown вызывается после yield break;. Один из них используется явно, а второй добавлен автоматически в конец метода компилятором.

А теперь выполним

var enumerator = CountDown(3, failAt: 1).GetEnumerator();
try
{
    int i;
    while (enumerator.MoveNext())
    {
        i = enumerator.Current;
        Console.WriteLine(i);
    }
}
finally
{
    // enumerator.Dispose();
}

и получим

3
2
1
Unhandled exception. System.Exception: Inner failure at count = 1
   at TryFinally.Program.CountDown(Int32 count, Nullable`1 stopAt, Nullable`1 failAt)+MoveNext() in C:\Users\Admin\source\repos\TryFinally\TryFinally\Program.cs:line 66
   at TryFinally.Program.Main(String[] args) in C:\Users\Admin\source\repos\TryFinally\TryFinally\Program.cs:line 40
Finally!!!

То есть исключение тоже запустило выполнение блока finally.

Таким образом, при использовании try-finally с yield return, блок finally выполняется:

• в enumerator.Dispose();

• после исключения

• и после yield break;

И не выполняется вовсе при невыполнении ни одного из этих условий.

Кстати

var enumerator = CountDown(3, failAt: 1).GetEnumerator();
enumerator.Dispose();

Все равно не запустит finally. Нужен хотябы один вызов enumerator.MoveNext().