в Орге есть класс который создает объект не существующего в орге класса (как это возможно?!). также я не нашел тестов его покрывающих.
и внезапно при деплое в этот Орг, при прогоне всех тестов, ВСЕ классы выпали по ошибке:
Details: line -1, column -1: Previous load of class failed: существующийКласс: line 6, column 64: Invalid type: несуществующийКласс.ЕгоВложенныйКласс.
не знаю, что и сказать. Может это обычное дело, что система при деплое проверяет все классы на конфликты в синтаксисе, даже если эти классы не вызываются тестами. Или это был глюк системы?
также я не могу понять КАК можно было удалить в Орге класс, которые требуется в другом месте кода.
дело в том что в другом Орге (Проде) этот класс сущетсвует, а вот в недавно созданной фул-копи сендбоксе этого класс уже нет!
Очень знакомая ошибка, но не скажу точно причину.
Но то что ничего тут особенного нет точно. Ищи ошибку в коде.
Да, проверяется весь код при деплое и если что-то отвалилось, то может быть такая ошибка.
Короче ничего путного я толком не сказал, но единственная мысль здесь 
- ищи проблему в своем коде.
там нет проблем.
просто требуемого класса нет физически.
как его можно было удалить??? система же не позволяет удалять код, если у него есть зависимые классы\тригеры...
и почему система позволита его удалить, но позже "озаботилась" его отсутвием так сильно, что начало выдать ошибку на каждом существующем классе (в тесте)...
PS: да, утверждают, что его действительно просто взяли и удалили...
Судя по всему, SF с определенного момента потихоньку "оптимизировал", сиречь ускорил деплой и теперь можно запросто грохнуть класс на который есть ссылки из других мест. Это если речь идёт о SB или DEV организации. Но предполагаю что такая ситуация может произойти и в PROD'е, например вот так:
1. деплой осуществлялся посредством unmanaged package - тогда, на сколько я помню, прогоняются тесты только внутри "пакета" и в теории можно похерить что-то рядом
2. деплой осуществлялся с использованием новой фичи
RunSpecifiedTestsи тоже похерилось кое-что лежащее рядом
спасибо Илья за важные комментарии.
но в том то и дело, что в том фул-копи сендбоксе этот класс был удален вручную через стандартный UI. по крайней мере они так утверждают, и я действительно верю, что это был единственный способ, каким они были "способны" произвести удаление
Если класс является интерфейсом и запускается динамически, то убийство этого класса не вызовет никаких ошибок.
Это уже проверено не один раз.
А вот я же и говорю, что в SB грохнуть класс, который где-то используется, теперь не особая проблема. SF может и делает какую-то быструю проверку по поводу использования его ещё где-то, но по всей видимости эта проверка сбоит. В общем главный вывод из всего этого - теперь разломать сэндбокс можно как два пальца об асфальт.
