Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T22:28:26Z

Nzlu:

== '''Eexpertiza''' ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.
== '''Rspec''' ==
Rspec is a meta-gem, which depends on the rspec-core, rspec-expectations and rspec-mocks gems. Each of these can be installed separately and loaded in isolation using require. Among other benefits, this allows you to use rspec-expectations, for example, in Test::Unit::TestCase if you happen to prefer that style.
Conversely, if you like RSpec's approach to declaring example groups and examples (describe and it) but prefer Test::Unit assertions and mocha, rr or flexmock for mocking, you'll be able to do that without having to install or load the components of RSpec that you're not using.
== '''Problem Statement''' ==
Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.

One reason is that we use fixture to create records in test DB each time running tests.

For example, the codes in quiz_spec.rb contain too much create so that prolong testing time.
<pre>
# Create an assignment due date
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create :assignment_due_date, due_at: (DateTime.now + 1)
</pre>

One solution is building an complete database to one time to support all RSpec test without create new records.

== '''Task''' ==
Formally, we need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type)).
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to Expertiza.
To finish these tasks, we need to modify all RSpec test files in Expertiza and using a new Database:Expertiza_test.

== '''Design''' ==
=== Database design ===
We design a expertiza_test database to save the test date used for Rspec. The test database owns the same structure as the real expertiza database, including the relations between tables and some restriction of attribute like it cannot be null or some other requirements for different attributes. Besides, the data in test database is the same as the data in factories part in spec, which includes FeedbackResponseMap.rb, Respone.rb, factories.rb, quiz_factory.rb. In this situation we do not need to create some data before testing, and we can use the data in test DB directly. Because of it, the overhead of testing cases will experience obvious decreasing.
like the Rspec statements in creating some User objects.:
factory :admin, class: User do
sequence(:name) {|n| "admin#{n}" }
role { Role.where(name: 'Administrator').first || association(:role_of_administrator) }
password "password"
password_confirmation "password"
sequence(:fullname) {|n| "#{n}, administrator" }
email "expertiza@mailinator.com"
parent_id 1
private_by_default false
mru_directory_path nil
email_on_review true
email_on_submission true
email_on_review_of_review true
is_new_user false
master_permission_granted 0
handle "handle"
leaderboard_privacy false
digital_certificate nil
timezonepref nil
public_key nil
copy_of_emails false
end

then transfer this into SQL query and then add the information the same as designed for Rspec test into expertiza_test database.
INSERT INTO User VALUES (xxxxx, xxxxxx, xxxxx, xxxxxxxx, xxxxxxx, xxxxxxx, xxxx );

=== feature test design ===
To accelerate the feature test, we have to eliminate pseudo data creation. Now all the feature tests have to create their own data before each test. After building a test database, all the pseudo data creation statement can be removed from the test files. Instead, the tests reference data stored in the test database.

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T22:27:45Z

Nzlu:

== '''Eexpertiza''' ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.
== '''Rspec''' ==
Rspec is a meta-gem, which depends on the rspec-core, rspec-expectations and rspec-mocks gems. Each of these can be installed separately and loaded in isolation using require. Among other benefits, this allows you to use rspec-expectations, for example, in Test::Unit::TestCase if you happen to prefer that style.
Conversely, if you like RSpec's approach to declaring example groups and examples (describe and it) but prefer Test::Unit assertions and mocha, rr or flexmock for mocking, you'll be able to do that without having to install or load the components of RSpec that you're not using.
== '''Problem Statement''' ==
Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.

One reason is that we use fixture to create records in test DB each time running tests.

For example, the codes in quiz_spec.rb contain too much create so that prolong testing time.
<pre>
# Create an assignment due date
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create :assignment_due_date, due_at: (DateTime.now + 1)
</pre>

One solution is building an complete database to one time to support all RSpec test without create new records.

== '''Task''' ==
Formally, we need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type)).
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to Expertiza.
To finish these tasks we need to modify all RSpec test files in Expertiza and using a new Database:Expertiza_test.

== '''Design''' ==
=== Database design ===
We design a expertiza_test database to save the test date used for Rspec. The test database owns the same structure as the real expertiza database, including the relations between tables and some restriction of attribute like it cannot be null or some other requirements for different attributes. Besides, the data in test database is the same as the data in factories part in spec, which includes FeedbackResponseMap.rb, Respone.rb, factories.rb, quiz_factory.rb. In this situation we do not need to create some data before testing, and we can use the data in test DB directly. Because of it, the overhead of testing cases will experience obvious decreasing.
like the Rspec statements in creating some User objects.:
factory :admin, class: User do
sequence(:name) {|n| "admin#{n}" }
role { Role.where(name: 'Administrator').first || association(:role_of_administrator) }
password "password"
password_confirmation "password"
sequence(:fullname) {|n| "#{n}, administrator" }
email "expertiza@mailinator.com"
parent_id 1
private_by_default false
mru_directory_path nil
email_on_review true
email_on_submission true
email_on_review_of_review true
is_new_user false
master_permission_granted 0
handle "handle"
leaderboard_privacy false
digital_certificate nil
timezonepref nil
public_key nil
copy_of_emails false
end

then transfer this into SQL query and then add the information the same as designed for Rspec test into expertiza_test database.
INSERT INTO User VALUES (xxxxx, xxxxxx, xxxxx, xxxxxxxx, xxxxxxx, xxxxxxx, xxxx );

=== feature test design ===
To accelerate the feature test, we have to eliminate pseudo data creation. Now all the feature tests have to create their own data before each test. After building a test database, all the pseudo data creation statement can be removed from the test files. Instead, the tests reference data stored in the test database.

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T22:25:46Z

Nzlu:

== '''Eexpertiza''' ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.
== '''Rspec''' ==
Rspec is a meta-gem, which depends on the rspec-core, rspec-expectations and rspec-mocks gems. Each of these can be installed separately and loaded in isolation using require. Among other benefits, this allows you to use rspec-expectations, for example, in Test::Unit::TestCase if you happen to prefer that style.
Conversely, if you like RSpec's approach to declaring example groups and examples (describe and it) but prefer Test::Unit assertions and mocha, rr or flexmock for mocking, you'll be able to do that without having to install or load the components of RSpec that you're not using.
== '''Problem Statement''' ==
Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.

One reason is that we use fixture to create records in test DB each time running tests.

For example, the codes in quiz_spec.rb contain too much create so that prolong testing time.
<pre>
# Create an assignment due date
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create :assignment_due_date, due_at: (DateTime.now + 1)
</pre>

One solution is building an complete database to one time to support all RSpec test without create new records.
== '''Related Work''' ==
* Classes involved: All RSpec test files in Expertiza.
* Database involved: Expertiza_test

== '''Task''' ==
Formally, we need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type)).
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to Expertiza.

== '''Design''' ==
=== Database design ===
We design a expertiza_test database to save the test date used for Rspec. The test database owns the same structure as the real expertiza database, including the relations between tables and some restriction of attribute like it cannot be null or some other requirements for different attributes. Besides, the data in test database is the same as the data in factories part in spec, which includes FeedbackResponseMap.rb, Respone.rb, factories.rb, quiz_factory.rb. In this situation we do not need to create some data before testing, and we can use the data in test DB directly. Because of it, the overhead of testing cases will experience obvious decreasing.
like the Rspec statements in creating some User objects.:
factory :admin, class: User do
sequence(:name) {|n| "admin#{n}" }
role { Role.where(name: 'Administrator').first || association(:role_of_administrator) }
password "password"
password_confirmation "password"
sequence(:fullname) {|n| "#{n}, administrator" }
email "expertiza@mailinator.com"
parent_id 1
private_by_default false
mru_directory_path nil
email_on_review true
email_on_submission true
email_on_review_of_review true
is_new_user false
master_permission_granted 0
handle "handle"
leaderboard_privacy false
digital_certificate nil
timezonepref nil
public_key nil
copy_of_emails false
end

then transfer this into SQL query and then add the information the same as designed for Rspec test into expertiza_test database.
INSERT INTO User VALUES (xxxxx, xxxxxx, xxxxx, xxxxxxxx, xxxxxxx, xxxxxxx, xxxx );

=== feature test design ===
To accelerate the feature test, we have to eliminate pseudo data creation. Now all the feature tests have to create their own data before each test. After building a test database, all the pseudo data creation statement can be removed from the test files. Instead, the tests reference data stored in the test database.

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T22:25:30Z

Nzlu:

== '''Eexpertiza''' ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.
== '''Rspec''' ==
rspec is a meta-gem, which depends on the rspec-core, rspec-expectations and rspec-mocks gems. Each of these can be installed separately and loaded in isolation using require. Among other benefits, this allows you to use rspec-expectations, for example, in Test::Unit::TestCase if you happen to prefer that style.
Conversely, if you like RSpec's approach to declaring example groups and examples (describe and it) but prefer Test::Unit assertions and mocha, rr or flexmock for mocking, you'll be able to do that without having to install or load the components of RSpec that you're not using.
== '''Problem Statement''' ==
Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.

One reason is that we use fixture to create records in test DB each time running tests.

For example, the codes in quiz_spec.rb contain too much create so that prolong testing time.
<pre>
# Create an assignment due date
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create :assignment_due_date, due_at: (DateTime.now + 1)
</pre>

One solution is building an complete database to one time to support all RSpec test without create new records.
== '''Related Work''' ==
* Classes involved: All RSpec test files in Expertiza.
* Database involved: Expertiza_test

== '''Task''' ==
Formally, we need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type)).
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to Expertiza.

== '''Design''' ==
=== Database design ===
We design a expertiza_test database to save the test date used for Rspec. The test database owns the same structure as the real expertiza database, including the relations between tables and some restriction of attribute like it cannot be null or some other requirements for different attributes. Besides, the data in test database is the same as the data in factories part in spec, which includes FeedbackResponseMap.rb, Respone.rb, factories.rb, quiz_factory.rb. In this situation we do not need to create some data before testing, and we can use the data in test DB directly. Because of it, the overhead of testing cases will experience obvious decreasing.
like the Rspec statements in creating some User objects.:
factory :admin, class: User do
sequence(:name) {|n| "admin#{n}" }
role { Role.where(name: 'Administrator').first || association(:role_of_administrator) }
password "password"
password_confirmation "password"
sequence(:fullname) {|n| "#{n}, administrator" }
email "expertiza@mailinator.com"
parent_id 1
private_by_default false
mru_directory_path nil
email_on_review true
email_on_submission true
email_on_review_of_review true
is_new_user false
master_permission_granted 0
handle "handle"
leaderboard_privacy false
digital_certificate nil
timezonepref nil
public_key nil
copy_of_emails false
end

then transfer this into SQL query and then add the information the same as designed for Rspec test into expertiza_test database.
INSERT INTO User VALUES (xxxxx, xxxxxx, xxxxx, xxxxxxxx, xxxxxxx, xxxxxxx, xxxx );

=== feature test design ===
To accelerate the feature test, we have to eliminate pseudo data creation. Now all the feature tests have to create their own data before each test. After building a test database, all the pseudo data creation statement can be removed from the test files. Instead, the tests reference data stored in the test database.

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T22:15:16Z

Nzlu:

== '''Eexpertiza''' ==
== '''Rspec''' ==
rspec is a meta-gem, which depends on the rspec-core, rspec-expectations and rspec-mocks gems. Each of these can be installed separately and loaded in isolation using require. Among other benefits, this allows you to use rspec-expectations, for example, in Test::Unit::TestCase if you happen to prefer that style.
Conversely, if you like RSpec's approach to declaring example groups and examples (describe and it) but prefer Test::Unit assertions and mocha, rr or flexmock for mocking, you'll be able to do that without having to install or load the components of RSpec that you're not using.
== '''Problem Statement''' ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.

One reason is that we use fixture to create records in test DB each time running tests.

For example, the codes in quiz_spec.rb contain too much create so that prolong testing time.
<pre>
# Create an assignment due date
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create :assignment_due_date, due_at: (DateTime.now + 1)
</pre>

One solution is building an complete database to one time to support all RSpec test without create new records.
== '''Related Work''' ==
* Classes involved: All RSpec test files in Expertiza.
* Database involved: Expertiza_test

== '''Task''' ==
Formally, you need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type)).
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to Expertiza.

== '''Design''' ==
=== Database design ===
We design a expertiza_test database to save the test date used for Rspec. The test database owns the same structure as the real expertiza database, including the relations between tables and some restriction of attribute like it cannot be null or some other requirements for different attributes. Besides, the data in test database is the same as the data in factories part in spec, which includes FeedbackResponseMap.rb, Respone.rb, factories.rb, quiz_factory.rb. In this situation we do not need to create some data before testing, and we can use the data in test DB directly. Because of it, the overhead of testing cases will experience obvious decreasing.
like the Rspec statements in creating some User objects.:
factory :admin, class: User do
sequence(:name) {|n| "admin#{n}" }
role { Role.where(name: 'Administrator').first || association(:role_of_administrator) }
password "password"
password_confirmation "password"
sequence(:fullname) {|n| "#{n}, administrator" }
email "expertiza@mailinator.com"
parent_id 1
private_by_default false
mru_directory_path nil
email_on_review true
email_on_submission true
email_on_review_of_review true
is_new_user false
master_permission_granted 0
handle "handle"
leaderboard_privacy false
digital_certificate nil
timezonepref nil
public_key nil
copy_of_emails false
end

then transfer this into SQL query and then add the information the same as designed for Rspec test into expertiza_test database.
=== feature test design ===
To accelerate the feature test, we have to eliminate pseudo data creation. Now all the feature tests have to create their own data before each test. After building a test database, all the pseudo data creation statement can be removed from the test files. Instead, the tests reference data stored in the test database.

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T22:14:43Z

Nzlu:

== '''Eexpertiza''' ==
== '''Rspec''' ==
rspec is a meta-gem, which depends on the rspec-core, rspec-expectations and rspec-mocks gems. Each of these can be installed separately and loaded in isolation using ''require''. Among other benefits, this allows you to use rspec-expectations, for example, in Test::Unit::TestCase if you happen to prefer that style.
Conversely, if you like RSpec's approach to declaring example groups and examples (describe and it) but prefer Test::Unit assertions and mocha, rr or flexmock for mocking, you'll be able to do that without having to install or load the components of RSpec that you're not using.
== '''Problem Statement''' ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.

One reason is that we use fixture to create records in test DB each time running tests.

For example, the codes in quiz_spec.rb contain too much create so that prolong testing time.
<pre>
# Create an assignment due date
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create :assignment_due_date, due_at: (DateTime.now + 1)
</pre>

One solution is building an complete database to one time to support all RSpec test without create new records.
== '''Related Work''' ==
* Classes involved: All RSpec test files in Expertiza.
* Database involved: Expertiza_test

== '''Task''' ==
Formally, you need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type)).
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to Expertiza.

== '''Design''' ==
=== Database design ===
We design a expertiza_test database to save the test date used for Rspec. The test database owns the same structure as the real expertiza database, including the relations between tables and some restriction of attribute like it cannot be null or some other requirements for different attributes. Besides, the data in test database is the same as the data in factories part in spec, which includes FeedbackResponseMap.rb, Respone.rb, factories.rb, quiz_factory.rb. In this situation we do not need to create some data before testing, and we can use the data in test DB directly. Because of it, the overhead of testing cases will experience obvious decreasing.
like the Rspec statements in creating some User objects.:
factory :admin, class: User do
sequence(:name) {|n| "admin#{n}" }
role { Role.where(name: 'Administrator').first || association(:role_of_administrator) }
password "password"
password_confirmation "password"
sequence(:fullname) {|n| "#{n}, administrator" }
email "expertiza@mailinator.com"
parent_id 1
private_by_default false
mru_directory_path nil
email_on_review true
email_on_submission true
email_on_review_of_review true
is_new_user false
master_permission_granted 0
handle "handle"
leaderboard_privacy false
digital_certificate nil
timezonepref nil
public_key nil
copy_of_emails false
end

then transfer this into SQL query and then add the information the same as designed for Rspec test into expertiza_test database.
=== feature test design ===
To accelerate the feature test, we have to eliminate pseudo data creation. Now all the feature tests have to create their own data before each test. After building a test database, all the pseudo data creation statement can be removed from the test files. Instead, the tests reference data stored in the test database.

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T22:11:50Z

Nzlu:

== '''Eexpertiza''' ==
== '''Rspec''' ==
rspec is a meta-gem, which depends on the rspec-core, rspec-expectations and rspec-mocks gems. Each of these can be installed separately and loaded in isolation using require. Among other benefits, this allows you to use rspec-expectations, for example, in Test::Unit::TestCase if you happen to prefer that style.
Conversely, if you like RSpec's approach to declaring example groups and examples (describe and it) but prefer Test::Unit assertions and mocha, rr or flexmock for mocking, you'll be able to do that without having to install or load the components of RSpec that you're not using.
== '''Problem Statement''' ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.
One reason is that we use fixture to create records in test DB each time running tests.
For example, the codes in quiz_spec.rb contain too much create so that prolong testing time.
<pre>
# Create an assignment due date
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create :assignment_due_date, due_at: (DateTime.now + 1)
</pre>

One solution is building an complete database to one time to support all RSpec test without create new records.
== '''Related Work''' ==
* Classes involved: All RSpec test files in Expertiza.
* Database involved: Expertiza_test

== '''Task''' ==
Formally, you need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type)).
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to Expertiza.

== '''Design''' ==
=== Database design ===
We design a expertiza_test database to save the test date used for Rspec. The test database owns the same structure as the real expertiza database, including the relations between tables and some restriction of attribute like it cannot be null or some other requirements for different attributes. Besides, the data in test database is the same as the data in factories part in spec, which includes FeedbackResponseMap.rb, Respone.rb, factories.rb, quiz_factory.rb. In this situation we do not need to create some data before testing, and we can use the data in test DB directly. Because of it, the overhead of testing cases will experience obvious decreasing.
like the Rspec statements in creating some User objects.:
factory :admin, class: User do
sequence(:name) {|n| "admin#{n}" }
role { Role.where(name: 'Administrator').first || association(:role_of_administrator) }
password "password"
password_confirmation "password"
sequence(:fullname) {|n| "#{n}, administrator" }
email "expertiza@mailinator.com"
parent_id 1
private_by_default false
mru_directory_path nil
email_on_review true
email_on_submission true
email_on_review_of_review true
is_new_user false
master_permission_granted 0
handle "handle"
leaderboard_privacy false
digital_certificate nil
timezonepref nil
public_key nil
copy_of_emails false
end

then transfer this into SQL query and then add the information the same as designed for Rspec test into expertiza_test database.
=== feature test design ===
To accelerate the feature test, we have to eliminate pseudo data creation. Now all the feature tests have to create their own data before each test. After building a test database, all the pseudo data creation statement can be removed from the test files. Instead, the tests reference data stored in the test database.

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T22:00:25Z

Nzlu:

== '''Eexpertiza''' ==
== '''Rspec''' ==
== '''Problem Statement''' ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.
Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.
One reason is that we use fixture to create records in test DB each time running tests.

== '''Related Work''' ==
* Classes involved: All RSpec test files in Expertiza.
* Database involved: Expertiza_test

== '''Task''' ==
Formally, you need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type))
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to expertiza.

== '''Design''' ==
=== Database design ===
=== factories design ===

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T22:00:04Z

Nzlu:

==Eexpertiza==
== Rspec ==
== '''Problem Statement''' ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.
Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.
One reason is that we use fixture to create records in test DB each time running tests.

== '''Related Work''' ==
* Classes involved: All RSpec test files in Expertiza.
* Database involved: Expertiza_test

== '''Task''' ==
Formally, you need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type))
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to expertiza.

== '''Design''' ==
=== Database design ===
=== factories design ===

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T21:58:56Z

Nzlu:

== '''Problem Statement''' ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.
Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.
One reason is that we use fixture to create records in test DB each time running tests.

== '''Related Work''' ==
* Classes involved: All RSpec test files in Expertiza.
* Database involved: Expertiza_test

== '''Task''' ==
Formally, you need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type))
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to expertiza.

== '''Design''' ==
=== Database design ===
=== factories design ===

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T21:57:50Z

Nzlu:

== Problem Statement ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.
Unfortunately, Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.
One reason is that we use fixture to create records in test DB each time running tests.

== Related Work ==
* Classes involved: All RSpec test files in Expertiza.
* Database involved: Expertiza_test

== Task ==
Formally, you need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type))
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to expertiza.

== Design ==
=== Database design ===
=== factories design ===

CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing

2016-11-08T21:45:17Z

Nzlu:

== Problem Statement ==
Expertiza tests are really slow. If you check the TravisCI, it needs more than 9 min to run all tests.
One reason is that we use fixture to create records in test DB each time running tests.

== Related Work ==
* Classes involved: All RSpec test files in Expertiza.
* Database involved: Expertiza_test

== Task ==
Formally, you need to:
* Create the records in test DB according to the content in fixtures.
* Check each test file and delete certain DB records creation code that insert default records (eg. create(:deadline_type))
* And keep all the test cases passing when using test DB and make sure the time running test cases is shorter than before.
* You should submit the sql file of test DB to expertiza.

CSC/ECE 517 Fall 2016/E1673. Refactor question type.rb

2016-11-05T01:24:21Z

Nzlu:

==Background==
Expertiza is an open source software to create reusable learning objects through peer review. It also supports team projects, and the submission of almost any document type, including URLs and wiki pages. It has following features:

*Enables students working together in a class and a topic
*Enables studnets to do peer review and improve both him/her and others' learn experience

== Reason for Refractor==
The purpose of this work is to rewrite part of the codes in the Criterion.rb, Scale.rb, Checkbox.rb, Dropdown.rb, Text_response.rb, Text_area.rb, Text_field.rb. This is because some of codes have bad writing sytle, or not followingg OO language rules, which confuse others to understand these code. The detail of the requirements are list below:

*Line is too long
*Some code found in other location and should put them in the parent class
*Method has too many lines
*Some of the code will cause security risk
*Using the old style validations
*Using a lower efficent way to do the loop

All of these requirements are based on a analysis software called [https://codeclimate.com code climate]

==Result==

[[File:Lzhang45_1.png]]
[[File:Lzhang45_2.png]]

== Code Changes ==
===text_field.rb===
Although it increase the number of classes, the length of function decrease and it's easy to read than before

1. Short the long line

2. Improve security by using safe_join

Previous
html.html_safe

Changed
safe_join([" ".html_safe, " ".html_safe], html.html_safe)
3. Short long method

Previous
html += '<label for="responses_' + count.to_s + '">' + self.txt + '</label>'
html += '<input id="responses_' + count.to_s + '_score" name="responses[' + count.to_s + '][score]" type="hidden" value="">'
html += '<input id="responses_' + count.to_s + '_comments" label=' + self.txt + ' name="responses[' + count.to_s + '][comment]" size=' + self.size.to_s + ' type="text"'
html += 'value="' + answer.comments unless answer.nil?
html += '">'
html += '</li><BR/><BR/>' if self.type == 'TextField' and self.break_before == false
def complete(count, answer = nil)
html = if self.type == 'TextField' and self.break_before == true
html += combine(count, answer)
end

Changed
def combline(count, answer = nil)
html = complete_helper_response_scores(count) + complete_helper_response_comments(count)
html += complete_helper_text(answer) + complete_helper_response_comments
html += complete_helper_final_judge
html
end

===text_response.rb===
It makes codes more readable. We also choose safe_join instead of html_safe to prevent security risks. However, we must use html_safe to keep the character encoding.

1. Use new style validations
Previous
validates_presence_of :size
Changed
validates :size, presence: true

2. Short the long line

3. Improve security by safe_join

Preivious
html.html_safe
Changed
safe_join(["<tr>".html_safe, "</tr>".html_safe], html.html_safe)

4. Short long method

Preivious
def edit(_count)
html = '<tr>'
html += '<td align="center"><a rel="nofollow" data-method="delete" href="/questions/' + self.id.to_s + '">Remove</a></td>'
html += '<td><input size="6" value="' + self.seq.to_s + '" name="question[' + self.id.to_s + '][seq]" id="question_' + self.id.to_s + '_seq" type="text"></td>'
html += '<td><textarea cols="50" rows="1" name="question[' + self.id.to_s + '][txt]" id="question_' + self.id.to_s + '_txt" placeholder="Edit question content here">' + self.txt + '</textarea></td>'
html += '<td><input size="10" disabled="disabled" value="' + self.type + '" name="question[' + self.id.to_s + '][type]" id="question_' + self.id.to_s + '_type" type="text">''</td>'
html += '<td></td>'
html += '<td>text area size <input size="6" value="' + self.size.to_s + '" name="question[' + self.id.to_s + '][size]" id="question_' + self.id.to_s + '_size" type="text"></td>'
html += '</tr>'
html.html_safe
end
Changed
def edit(_count)
html = edit_link + edit_question_lable
html += edit_question_textarea + edit_question_textarea_size
safe_join(["<tr>".html_safe, "</tr>".html_safe], html.html_safe)
end

===scale.rb===
1. Use each loop instead of for loop

Previous
for j in questionnaire_min..questionnaire_max
html += '<td width="10%"><input type="radio" id="' + j.to_s + '" value="' + j.to_s + '" name="Radio_' + self.id.to_s + '"'
html += 'checked="checked"' if (!answer.nil? and answer.answer == j) or (answer.nil? and questionnaire_min == j)
html += '></td>'
end

Changed
(questionnaire_min..questionnaire_max).each do |j|
html += '<td width="10%"><input type="radio" id="' + j.to_s + '" value="' + j.to_s + '" name="Radio_' + self.id.to_s + '"'
html += 'checked="checked"' if (!answer.nil? and answer.answer == j) or (answer.nil? and questionnaire_min == j)
html += '></td>'
end
2. Short the long line

3. Use safe_join to be more security

Previous
html.html_safe

Changed
safe_join(["".html_safe, "".html_safe], html.html_safe

4. Delete the code similar with other file and put the duplicate into parent class.

5. Modify some method that is too long

Previous
def edit(_count)
html = '<tr>'
html += '<td align="center"><a rel="nofollow" data-method="delete" href="/questions/' + self.id.to_s + '">Remove</a></td>'
html += '<td><input size="6" value="' + self.seq.to_s + '" name="question[' + self.id.to_s + '][seq]" id="question_' + self.id.to_s + '_seq" type="text"></td>'
html += '<td><textarea cols="50" rows="1" name="question[' + self.id.to_s + '][txt]" id="question_' + self.id.to_s + '_txt" placeholder="Edit question content here">' + self.txt + '</textarea></td>'
html += '<td><input size="10" disabled="disabled" value="' + self.type + '" name="question[' + self.id.to_s + '][type]" id="question_' + self.id.to_s + '_type" type="text">''</td>'
html += '<td><input size="2" value="' + self.weight.to_s + '" name="question[' + self.id.to_s + '][weight]" id="question_' + self.id.to_s + '_weight" type="text">''</td>'
html += '<td> max_label <input size="10" value="' + self.max_label.to_s + '" name="question[' + self.id.to_s + '][max_label]" id="question_' + self.id.to_s + '_max_label" type="text"> min_label <input size="12" value="' + self.min_label.to_s + '" name="question[' + self.id.to_s + '][min_label]" id="question_' + self.id.to_s + '_min_label" type="text"></td>'
html += '</tr>'
html.html_safe
end

Changed
def edit(count)
html = edit_remove_button(count) + edit_seq(count)
html += edit_question_type(count) + edit_weight(count)
html += edit_max_label(count) + edit_min_label(count)
safe_join([raw("<tr>"), raw("</tr>")], raw(html))
end

===checkbox.rb===
1. Short the long line

2. Modify some method that is too long
Previous

def edit(_count)
html = '<tr>'
html += '<td align="center"><a rel="nofollow" data-method="delete" href="/questions/' + self.id.to_s + '">Remove</a></td>'
html += '<td><input size="6" value="' + self.seq.to_s + '" name="question[' + self.id.to_s + '][seq]" id="question_' + self.id.to_s + '_seq" type="text"></td>'
html += '<td><textarea cols="50" rows="1" name="question[' + self.id.to_s + '][txt]" id="question_' + self.id.to_s + '_txt" placeholder="Edit question content here">' + self.txt + '</textarea></td>'
html += '<td><input size="10" disabled="disabled" value="' + self.type + '" name="question[' + self.id.to_s + '][type]" id="question_' + self.id.to_s + '_type" type="text">''</td>'
html += '<td></td>'
html += '</tr>'
html.html_safe
end

Changed

def edit(count)
html = edit_remove_button(count) + edit_seq(count) + edit_question(count)
html += edit_type(count) + edit_weight(count)
safe_join(["<tr>".html_safe, "</tr>".html_safe], html.html_safe)
end

3. Use safe_join to be more security

Previous
html.html_safe

Changed
safe_join(["".html_safe, "".html_safe], html.html_safe

===criterion.rb===
1. Improve security by using safe_join

Previous
html.html_safe
Changed
safe_join(["".html_safe, "".html_safe], html.html_safe)

2. Modify some method that is too long

3. Use new style validations

Previous
validates_presence_of :size
Changed
validates :size, presence: true

4. Use each loop instead of for loop

Previous
for j in questionnaire_min..questionnaire_max
Changed
(questionnaire_min..questionnaire_max).each do |j|

===dropdown.rb===
1. Use new style validations

Previous
validates_presence_of :alternatives
Changed
validates :alternatives, presence: true

2. Modify some method that is too long

3. Improve security by using safe_join

Previous
html.html_safe

Changed
safe_join(["".html_safe, "".html_safe], html.html_safe)

===text_area.rb===
1. Replace condition statements in one line

Previous
if self.size.nil?
cols = '70'
ows = '1'
elsif
cols = self.size.split(',')[0]
rows = self.size.split(',')[1]
end

Changed
def complete_get_cols_rows
return '70', '1' if self.size.nil?
[self.size.split(',')[0], self.size.split(',')[1]]
end

2. Improve security by using safe_join

Previous
html.html_safe

Changed
safe_join(["".html_safe, "".html_safe], html.html_safe)

==Test from UI==
* Login in as an instructor or admin using credentials (admin with password: admin or instructor6 with password: password)

*Click the Manage in the top bar,then click the Questionnaires which is down left of the the text:Manage content

*Add the Name and click create

*Click the any button you want

CSC/ECE 517 Fall 2016/E1673. Refactor question type.rb

2016-11-05T00:50:52Z

Nzlu: /* Code Changes */

CSC/ECE 517 Fall 2016/E1673. Refactor question type.rb

2016-10-29T02:52:46Z

Nzlu: /* Code Changes */

CSC/ECE 517 Fall 2016/E1673. Refactor question type.rb

2016-10-29T02:52:14Z

Nzlu: /* Code Changes */

CSC/ECE 517 Fall 2016/E1673. Refactor question type.rb

2016-10-29T02:34:45Z