StaticPagesController.rb
def home
end
def help
end
I was wondering why it works even though I didn't write anything. ⇒It seems that the description about the default behavior is omitted. For beginners, it will be (.´ ・ ω ・)?
StaticPagesController.rb
def home
#app/views/static_pages/home.html.Run erb(Omitted description)
end
def help
#app/views/static_pages/help.html.Run erb(Omitted description)
end
The next thing I stumbled upon was the test ... I didn't deal with it in the Tech :: Camp curriculum at all, so I didn't have any prior knowledge (.´ ・ ω ・)?
It seems to be a thing to develop while testing. The minitest used in Rails Tutorial is a simple thing, It seems that tools such as Rspec and Capybara are commonly used.
(´-ω-`) I learned more after finishing the tutorial ...
For specifications that have been set in advance, "Write a test" ⇒ "Implement" ⇒ "Test"
Things that change while making designs, etc. "Implement" ⇒ "Write test" ⇒ "Test"
If the test code is obviously shorter and easier to write than the application code), write it "first" If the behavioral specifications are not complete, write the application code first and the expected behavior "later". Write tests "first" when security-critical issues or security-related errors occur If you find a bug, write a test that reproduces the bug "first", put in place a system to prevent regression bugs, and start fixing it. Write tests "later" for code that is likely to change again soon (such as HTML structure details) When refactoring, write the test "first". In particular, intensively test code that is likely to cause errors or stop.
There is no development without testing ... It seems very important to be able to write tests.
test/controllers/static_pages_controller_test.rb
require 'test_helper'
class StaticPagesControllerTest < ActionDispatch::IntegrationTest
test "should get home" do
get static_pages_home_url #Access the URL
assert_response :success #← Test part[Check if the HTML page comes back]
end
test "should get help" do
get static_pages_help_url
assert_response :success
end
end
3.6 Advanced setup This additional section describes the test settings. Broadly speaking, there are two types: "minitest reporters (3.6.1)" that sets the display of success / failure, and "Guard (3.6.2)" that detects changes in files and automatically executes only the necessary tests. It is one. The code provided for reference in this section is reasonably advanced and does not need to be understood right away.
Guard monitors file system changes and For example, a tool that automatically executes a test when you change the static_pages_test.rb file, etc.
Oh, it looks really convenient (*'▽')
Guardfile
#Define Guard matching rules
guard :minitest, spring: "bin/rails test", all_on_start: false do
watch(%r{^test/(.*)/?(.*)_test\.rb$})
watch('test/test_helper.rb') { 'test' }
watch('config/routes.rb') { interface_tests }
watch(%r{app/views/layouts/*}) { interface_tests }
watch(%r{^app/models/(.*?)\.rb$}) do |matches|
"test/models/#{matches[1]}_test.rb"
end
watch(%r{^app/controllers/(.*?)_controller\.rb$}) do |matches|
resource_tests(matches[1])
end
watch(%r{^app/views/([^/]*?)/.*\.html\.erb$}) do |matches|
["test/controllers/#{matches[1]}_controller_test.rb"] +
integration_tests(matches[1])
end
watch(%r{^app/helpers/(.*?)_helper\.rb$}) do |matches|
integration_tests(matches[1])
end
watch('app/views/layouts/application.html.erb') do
'test/integration/site_layout_test.rb'
end
watch('app/helpers/sessions_helper.rb') do
integration_tests << 'test/helpers/sessions_helper_test.rb'
end
watch('app/controllers/sessions_controller.rb') do
['test/controllers/sessions_controller_test.rb',
'test/integration/users_login_test.rb']
end
watch('app/controllers/account_activations_controller.rb') do
'test/integration/users_signup_test.rb'
end
watch(%r{app/views/users/*}) do
resource_tests('users') +
['test/integration/microposts_interface_test.rb']
end
end
#Returns an integration test for a given resource
def integration_tests(resource = :all)
if resource == :all
Dir["test/integration/*"]
else
Dir["test/integration/#{resource}_*.rb"]
end
end
#The interface returns all applicable tests
def interface_tests
integration_tests << "test/controllers/"
end
#Returns the controller test for the given resource
def controller_test(resource)
"test/controllers/#{resource}_controller_test.rb"
end
#Returns all tests corresponding to a given resource
def resource_tests(resource)
integration_tests(resource) << controller_test(resource)
end
For the time being, if you change a specific file, it's like running the file in the test folder. It seems that automatic test monitoring starts by executing the following command after setting this file.
$ echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p
$ bundle exec guard
$ bin/spring stop #If the test doesn't work for unknown reasons, try running this command
$ bundle exec guard
I don't think I can customize it myself (^ ω ^) ...
config/routes.rb Write a description that executes the controller # action when there is access to
config/routes.rb
Rails.application.routes.draw do
get 'static_pages/home' #I don't use this description very often.
#get 'static_pages/home' => "static_pages#home"I feel that it is common to write like this.
get 'static_pages/help'
root 'application#hello'
end
app/controller/StaticPagesController.rb Describe the content of each action.
app/controller/StaticPagesController.rb
def home
#app/views/static_pages/home.html.Run erb(Omitted description)
end
def help
#app/views/static_pages/help.html.Run erb(Omitted description)
end
The screen displayed to the user is a view file (storage location is app / views / controller name /xxx.html.erb) erb is embedded ruby (a convenient extension for embedding Ruby in html files) The part surrounded by <%> <%> is the Ruby code part.
app/views/layouts/application.html.erb Share the common HTML part in app / views / layouts / application.html.erb
erb:app/views/layouts/application.html.erb
<!DOCTYPE html>
<html>
<head>
<title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
<%= csrf_meta_tags %>
<%= csp_meta_tag %>
<%= stylesheet_link_tag 'application', media: 'all',
'data-turbolinks-track': 'reload' %>
<%= javascript_pack_tag 'application',
'data-turbolinks-track': 'reload' %>
</head>
<body>
<%= yield %>
</body>
</html>
To pass the page title, describe the provide method <% provide (: title, "Home")%> in each view.
erb:app/views/static_pages/home.html.erb
<% provide(:title, "Home") %>
<h1>Sample App</h1>
<p>
This is the home page for the
<a href="https://railstutorial.jp/">Ruby on Rails Tutorial</a>
sample application.
</p>
By writing the test in test / controllers / static_pages_controller_test.rb, You can test the response, title name, page element, etc. when accessing each page.
test/controllers/static_pages_controller_test.rb
require 'test_helper'
class StaticPagesControllerTest < ActionDispatch::IntegrationTest
def setup
@base_title = "Ruby on Rails Tutorial Sample App"
end
test "should get home" do
get static_pages_home_url
assert_response :success
assert_select "title", "Home | #{@base_title}"
end
test "should get help" do
get static_pages_help_url
assert_response :success
assert_select "title", "Help | #{@base_title}"
end
test "should get about" do
get static_pages_about_url
assert_response :success
assert_select "title", "About | #{@base_title}"
end
end
| item | Create | How to undo |
|---|---|---|
| controller | rails generate controller StaticPages home help | rails destroy controller StaticPages home help |
| model | rails generate model User name:string email:string | rails destroy model User |
| Database | rails db:migrate | rails db:rollback(Return to the previous state) |
| Database | rails db:migrate | $ rails db:migrate VERSION=0(Return to the initial state) |
| Complete command | Shortened form |
|---|---|
| rails generate | rails g |
| rails destroy | rails d |
| rails test | rails t |
| rails console | rails c |
| bundle install | bundle |
Linux commands can be customized by editing a file called .bashrc ('ω')
#STEP1 - c9 ~/.Open the file with bashrc.
c9 ~/.bashrc
#STEP2 -Register the abbreviated command at the end of the sentence as shown below
alias r='rails'
alias g='git'
STEP3 - source ~/.Execute bashrc to read the registered abbreviated command
source ~/.bashrc
#STEP4
Enter r c and check if the rails console starts up.('ω')No
While watching the Rails Tutorial video (29,800 yen), I output it to Qiita after reviewing it, I am satisfied with the explanation of useful functions that are not described in the web text version. Until now, the c9 command was used to open a file. When the open option was added to the c9 command, it was an eyebrow that a new file was created when the file did not exist. After all, it's easier to get people to explain it. It's a little expensive, but I highly recommend the video materials. You can study various contents for free to low price on online learning sites such as Udemy, Coursera, and EduX.
Udemy (https://www.udemy.com/) Coursera (https://ja.coursera.org/) EdX (https://www.edx.org/)
c9 open app/views/static_pages/about.html.erb
After that, it seems that you can search files on cloud9 with Ctrl + p ('ω') ノ I recommend not using Ctrl + p at first as I remember where and what is by opening the folder every time. Well, if you have trouble opening the folder one by one, please use it.
This time, a new content called a test was introduced, so it was quite rich. I always read the same content several times. Especially since I have a bad memory, I feel like I can finally remember it over and over again. When I review it, I notice something different from when I read it the first time. Please read it several times instead of just once ('ω') ノ
Recommended Posts