vsuhachev

Запрос идет в контроллер. Его нужно обработать.
Что бы правильно работали все эти remote: true должна быть подключена библиотека, например, с джиквери -
//=require jquery
//=require jquery_ujs
Тогда появится магическое поведение всех этих аттрибутов.

После чего, запрос попадает в тот же контроллер, что обычно, но с форматом js

В простейшем случае, Вам нужно просто добавить вью, в вашем случае:
views/main/index.js.erb

И в нем написать javascript код, который будет реализовывать "показать больше". Например, вставить (append) полученные переменные (новые новости из контроллера).

Если логика для html и js форматов будет отличаться, тогда в экшене пишете

# news_controllerb.rb
def index
#common format code
@news = News.all
respond_to do |format|
format.html{ #html specific code }
format.js{ #js specific code }
end
end

Но вот ваше
(:countNews => @news.count + 9)

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

UPD:
Проверять запросы нужно с помощью гемов pry или byebug. Ставите точку останова в нужно месте в контроллере (где ждете запрос) и смотрите, что там где находится.

Вместо алертов используйте console.log()

Что происходит с запросом, смотрите в браузере во вкладке Network

Потому что каждый раз при деплое Capistrano создает новую директорию, в которую загружается свежий релиз вашего приложения. Соответственно, ваши изображения остаются в старой директории. Вам нужно настроить в файле deploy.rb симлинк с папками, в которых будут храниться изображения, сами эти папки обычно хранятся в директории shared выше по дереву относительно директории, содержащей релизы. Надеюсь, понятно объяснил :)

И судя по тому, что информация в БД у вас затирается, вы используете SQLite3 в качестве базы данных. Локум предоставляет для каждого проекта базу данных на PostgreSQL, MySQL или какую-то еще на выбор, рекомендую перебраться в PostgreSQL. Эта БД - де-факто стандарт для приложений на Rails, хотя иной раз выбор зависит от проекта. А SQLite - это только для этапа, когда разработка на Rails только-только постигается. Раньше переберетесь - проще будет в дальнейшем.

.gsub(/[^@](?=.*?@)/, ?x)

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

Модульные, они же юнит тесты, предназначены для тестирования отдельных модулей/классов. Суть их в том, что мы тестируем поведение только одного класса за раз. Если класс ссылается на инстансы других классов - мы их мокаем. То есть подсовываем им фэйковый класс, который имеет тот же интерфейс, но внутри не реализациа методов, а проверка, вызывали ли метод, с каким аргументами, сколько раз вызывали и т.д. Так же методы мока могут возвращать стабы (заглушки), какие-то захардкоженные под какой-то кейс данные. То есть если мы пишем класс по работе с базой данных, сокет-сервер и т.д., нам стоит соединение с базой, сокеты и т.д. оборачивать в классы, что бы можно было потом подменить на моки это добро. Если у вас в юнит тестах идет реальная работа с файловой системой или что-либо в этом духе, то это уже попахивает интеграционными тестами. Подробнее можно почитать в документации к phpunit. Так же есть такая методология разработки как TDD, советую почитать "Экстримальное программирование" Кента Бэка в этом ключе.

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

Интеграционное тестирование - тестирование нескольких модулей в связке. То есть мы тестируем наш компонент или его самодостаточный кусок в реальных условиях. Если этот компонент для работы с файлами - разрешаем ему доступ к файлам. Если база данных - то даем реальное соединение с базой. А можем что-то и замокать. Это как говорится, зависит от задачи. Скажем обращение к сторонним апишкам стоит мокать и стабить. Главная цель этих тестов, удостовериться что модули вместе работают хорошо. Особенно важно это когда модули пишут разные люди.

Функциональное тестирование - это тестирования всего приложения в сборе. Если это REST API, то у нас через curl дергаются реальные методы, отправляются более менее реальные запросы и валидируются ответы. Если web-страничка, то это UI тесты с силениумом/phantom.js/zombi.js или, если нам не нужно еще и js тестить, просто curl + какой виртуальный браузер на том же php. Вообще по хорошему функциональные тесты не допускают никаких моков и т.д. но опять же если очень хочется то можно (опять же обращение к сторонним сервисам, контроля за которыми у нас нету).

Но реалии таковы, что UI тестами покрывать проект не слишком удобно. Вопервых UI может меняться, а поддерживать их так же нужно. Во вторых это скучно. В третьих тесты могут просто падать... вот взяли и упали. И потом начинается, так, тесты опять упали... что там упало? А, не страшно, можно релизить. Так же на больших проектах UI тесты отрабатывают долго, очень долго, некоторых их просто ночью гоняют. Толку от тестов при таком подходе не слишком много, ибо разработчику стоит знать о том что что-то сломалось как можно быстрее. А так он приходит, видит что тесты опять красные, чинит эти красные тесты, и запускает... ждет... проходит пол часа к примеру, и где-то в другом месте отвалилось... Короче сами понимаете.

Приемочное тестирование - по сути те же функциональные тесты, но подаются в контексте фича-спеков. Если вы работали когда-нибудь с QA отделом, то возможно слышали про такие штуки как acceptance criteria. То есть это тот чек лист, который должен проверить тестировщик что бы удостовериться что все хорошо. На основе этого чек листа можно написать функциональные тесты. Так же есть инструменты вроде Cucumber/Behat, которые позволяют писать спецификации в виде стэпов. В этом случае спецификации для этих инструментов могут писать QA а вы просто имплементите для них степы. То есть уменьшается прослойка между "acceptance criteria" и готовыми к выполнению тестов. Более того, стэпы можно реюзать, комбинировать, масса стэпов есть готовых, вам же необходимо только предоставить стэпы подготвалливающие систему (загрузка/генерация фикстур и т.д.). Короче лепота и удобно. Но медленнее интеграционных, зато не такие жесткие как функциональные, за счет этого их проще поддерживать. QA пишут спеку, реализуем тесты под эту спеку, пишем код под тесты, тесты зеленые - функционал готов.

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

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

Короче почитайте про TDD и ATDD (можно и BDD затронуть, но тут не только от программиста зависит, менеджеры, заказчик или продукт-оунер тоже должны быть вовлечены, по сути этот подход хорошо работает в рамках продукта какого-то, на фрилансе и в аутсорсе редко можно встретить) , Continious Integration и Continious Delivery.

Есть такой gem - https://github.com/pokonski/public_activity
У railscasts есть скринкаст как сделать это с нуля - railscasts.com/episodes/407-activity-feed-from-scratch но там показываются нотификации для всего и всех.

Я же сделал так:
миграция

class CreateActivities < ActiveRecord::Migration
  def change
    create_table :activities do |t|

      t.integer :user_id # кому нотификация
      t.integer :author_id # кто сделал действие
      t.string :action # какое действие например create значит что то создалось
      t.integer :trackable_id #полиморфизм
      t.string :trackable_type #полиморфизм
      t.boolean :read, default: false
      t.timestamps
    end

    add_index :activities, [:trackable_id, :trackable_type]
    add_index :activities, :user_id
    add_index :activities, :author_id
    add_index :activities, :read
  end
end

потом в applicationController.rb есть такой метод

def create_activity(to, author, action, trackable)
    activity = to.activities.build
    activity.author = author
    activity.action = action
    activity.trackable = trackable #полиморфизм обьект над которым произвелось действие
    activity.save
  end

и потом в любом контролере
например юзер отсылает сообщение другому юзеру или кто то оставляет комментарий вообщем любое действие

create_activity(@user, current_user, 'create', @post)

в итоге у вас потом такая лента примерно toster.ru/my/tracker как у тостера
если взять все уведомления у юзера

@activities = current_user.activities.includes(:author, :trackable).order(created_at: :desc)

в view у вас всё есть, кому нотификация, действие которое было сделанно и обьект на который вы можете дать ссылку
например вот так, но это частный случай у вас конечно будет подругому

<%= link_to activity.author.username, user_path(activity.author) %> ответил на сообщение <%= link_to activity.trackable.conversation.title, my_conversation_path(activity.trackable.conversation) %>

Будет написанно например
FanKiLL ответил на сообщение название сообщения
или
FanKiLL написал новый пост

Вообщем предлогаю посмотреть gem и скринкаст что я дал вначале - а там и этот код будет более понятен - если что спрашивайте.

когда юзер заходит на страницу с нотификациями все не прочитанные сообщения помечаются как прочитанные а до этого можете где хотите выводить список не прочитанных сообщений

current_user.activities.where(read: false).count