A Guide to Testing Rails Applications
This guide covers built-in mechanisms offered by Rails to test your application. By referring to this guide, you will be able to:
-
Understand Rails testing terminology
-
Write unit, functional and integration tests for your application
-
Identify other popular testing approaches and plugins
This guide won't teach you to write a Rails application; it assumes basic familiarity with the Rails way of doing things.
1. Why Write Tests for your Rails Applications?
-
Because Ruby code that you write in your Rails application is interpreted, you may only find that it's broken when you actually run your application server and use it through the browser. Writing tests is a clean way of running through your code in advance and catching syntactical and logic errors.
-
Rails tests can also simulate browser requests and thus you can test your application's response without having to test it through your browser.
-
By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring.
-
Rails makes it super easy to write your tests. It starts by producing skeleton test code in background while you are creating your models and controllers.
2. Before you Start Writing Tests
Just about every Rails application interacts heavily with a database - and, as a result, your tests will need a database to interact with as well. To write efficient tests, you'll need to understand how to set up this database and populate it with sample data.
2.1. The 3 Environments
Testing support was woven into the Rails fabric from the beginning. It wasn't an "oh! let's bolt on support for running tests because they're new and cool" epiphany. One of the consequences of this design decision is that every Rails application you build has 3 sides: a side for production, a side for development, and a side for testing.
One place you'll find this distinction is in the config/database.yml file. This YAML configuration file has 3 different sections defining 3 unique database setups:
-
production
-
development
-
test
This allows you to set up and interact with test data without any danger of your tests altering data from your production environment.
For example, suppose you need to test your new delete_this_user_and_every_everything_associated_with_it function. Wouldn't you want to run this in an environment where it makes no difference if you destroy data or not?
When you do end up destroying your testing database (and it will happen, trust me), you can rebuild it from scratch according to the specs defined in the development database. You can do this by running rake db:test:prepare.
2.2.  If you list the contents of this folder then you shall see:
$ ls -F test/ fixtures/ functional/ integration/ test_helper.rb unit/
The unit folder is meant to hold tests for your models, the functional folder is meant to hold tests for your controllers, and the integration folder is meant to hold tests that involve any number of controllers interacting. Fixtures are a way of organizing test data; they reside in the fixtures folder. The test_helper.rb file holds the default configuration for your tests.
2.3. The Low-Down on Fixtures
For good tests, you'll need to give some thought to setting up test data. In Rails, you can handle this by defining and customizing fixtures.
2.3.1. What Are Fixtures?
Fixtures is a fancy word for sample data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent and assume one of two formats: YAML or CSV.
You'll find fixtures under your test/fixtures directory. When you run script/generate model to create a new model, fixture stubs will be automatically created and placed in this directory.
2.3.2. YAML the Camel is a Mammal with Enamel
YAML-formatted fixtures are a very human-friendly way to describe your sample data. These types of fixtures have the .yml file extension (as in users.yml).
Here's a sample YAML fixture file:
# low & behold! I am a YAML comment! david: id: 1 name: David Heinemeier Hansson birthday: 1979-10-15 profession: Systems development steve: id: 2 name: Steve Ross Kellock birthday: 1974-09-27 profession: guy with keyboard
Each fixture is given a name followed by an indented list of colon-separated key/value pairs. Records are separated by a blank space. You can place comments in a fixture file by using the # character in the first column.
2.3.3. Comma Seperated
Fixtures can also be described using the all-too-familiar comma-separated value (CSV) file format. These files, just like YAML fixtures, are placed in the test/fixtures directory, but these end with the .csv file extension (as in celebrity_holiday_figures.csv).
A CSV fixture looks like this:
id, username, password, stretchable, comments 1, sclaus, ihatekids, false, I like to say ""Ho! Ho! Ho!"" 2, ebunny, ihateeggs, true, Hoppity hop y'all 3, tfairy, ilovecavities, true, "Pull your teeth, I will"
The first line is the header. It is a comma-separated list of fields. The rest of the file is the payload: 1 record per line. A few notes about this format:
-
Leading and trailing spaces are trimmed from each value when it is imported
-
If you use a comma as data, the cell must be encased in quotes
-
If you use a quote as data, you must escape it with a 2nd quote
-
Don't use blank lines
-
Nulls can be defined by including no data between a pair of commas
Unlike the YAML format where you give each record in a fixture a name, CSV fixture names are automatically generated. They follow a pattern of "model-name-counter". In the above example, you would have:
-
celebrity-holiday-figures-1
-
celebrity-holiday-figures-2
-
celebrity-holiday-figures-3
The CSV format is great to use if you have existing data in a spreadsheet or database and you are able to save it (or export it) as a CSV.
2.3.4. ERb'in It Up
ERb allows you embed ruby code within templates. Both the YAML and CSV fixture formats are pre-processed with ERb when you load fixtures. This allows you to use Ruby to help you generate some sample data.
I'll demonstrate with a YAML file:
<% earth_size = 20 -%> mercury: id: 1 size: <%= earth_size / 50 %> venus: id: 2 size: <%= earth_size / 2 %> mars: id: 3 size: <%= earth_size - 69 %>
Anything encased within the
<% %>
tag is considered Ruby code. When this fixture is loaded, the size attribute of the three records will be set to 20/50, 20/2, and 20-69 respectively.
2.3.5. Fixtures in Action
Rails by default automatically loads all fixtures from the test/fixtures folder for your unit and functional test. Loading involves three steps:
-
Remove any existing data from the table corresponding to the fixture
-
Load the fixture data into the table
-
Dump the fixture data into a variable in case you want to access it directly
2.3.6. Hashes with Special Powers
Fixtures are basically Hash objects. As mentioned in point #3 above, you can access the hash object directly because it is automatically setup as a local variable of the test case. For example:
# this will return the Hash for the fixture named david users(:david) # this will return the property for david called id users(:david).id
But, by there's another side to fixtures… at night, if the moon is full and the wind completely still, fixtures can also transform themselves into the form of the original class!
Now you can get at the methods only available to that class.
# using the find method, we grab the "real" david as a User david = users(:david).find # and now we have access to methods only available to a User class email(david.girlfriend.email, david.location_tonight)
3. Unit Testing Your Models
In Rails, unit tests are what you write to test your models.
When you create a model using script/generate, among other things it creates a test stub in the test/unit folder, as well as a fixture for the model:
$ script/generate model Post ... create app/models/post.rb create test/unit/post_test.rb create test/fixtures/posts.yml ...
The default test stub in test/unit/post_test.rb looks like this:
require 'test_helper' class PostTest < ActiveSupport::TestCase # Replace this with your real tests. def test_truth assert true end end
A line by line examination of this file will help get you oriented to Rails testing code and terminology.
require 'test_helper'
As you know by now that test_helper.rb specifies the default configuration to run our tests. This is included with all the tests, so any methods added to this file are available to all your tests.
class PostTest < ActiveSupport::TestCase
The PostTest class defines a test case because it inherits from ActiveSupport::TestCase. PostTest thus has all the methods available from ActiveSupport::TestCase. You'll see those methods a little later in this guide.
def test_truth
Any method defined within a test case that begins with test (case sensitive) is simply called a test. So, test_password, test_valid_password and testValidPassword all are legal test names and are run automatically when the test case is run.
assert true
This line of code is called an assertion. An assertion is a line of code that evaluates an object (or expression) for expected results. For example, an assertion can check:
-
is this value = that value?
-
is this object nil?
-
does this line of code throw an exception?
-
is the user's password greater than 5 characters?
Every test contains one or more assertions. Only when all the assertions are successful the test passes.
3.1. Running Tests
Running a test is as simple as invoking the file containing the test cases through Ruby:
$ cd test $ ruby unit/post_test.rb Loaded suite unit/post_test Started . Finished in 0.023513 seconds. 1 tests, 1 assertions, 0 failures, 0 errors
This will run all the test methods from the test case.
You can also run a particular test method from the test case by using the -n switch with the test method name.
$ ruby unit/post_test.rb -n test_truth Loaded suite unit/post_test Started . Finished in 0.023513 seconds. 1 tests, 1 assertions, 0 failures, 0 errors
The . (dot) above indicates a passing test. When a test fails you see an F; when a test throws an error you see an E in its place. The last line of the output is the summary.
To see how a test failure is reported, you can add a failing test to the post_test.rb test case:
def test_should_have_atleast_one_post post = Post.find(:first) assert_not_nil post end
If you haven't added any data to the test fixture for posts, this test will fail. You can see this by running it:
$ ruby unit/post_test.rb Loaded suite unit/post_test Started F. Finished in 0.027274 seconds. 1) Failure: test_should_have_atleast_one_post(PostTest) [unit/post_test.rb:12:in `test_should_have_atleast_one_post' /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/testing/setup_and_teardown.rb:33:in `__send__' /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/testing/setup_and_teardown.rb:33:in `run']: <nil> expected to not be nil. 2 tests, 2 assertions, 1 failures, 0 errors
In the output, F denotes a failure. You can see the corresponding trace shown under 1) along with the name of the failing test. The next few lines contain the stack trace followed by a message which mentions the actual value and the expected value by the assertion. The default assertion messages provide just enough information to help pinpoint the error. To make the assertion failure message more readable every assertion provides an optional message parameter, as shown here:
def test_should_have_atleast_one_post post = Post.find(:first) assert_not_nil post, "Should not be nil as Posts table should have atleast one post" end
Running this test shows the friendlier assertion message:
$ ruby unit/post_test.rb Loaded suite unit/post_test Started F. Finished in 0.024727 seconds. 1) Failure: test_should_have_atleast_one_post(PostTest) [unit/post_test.rb:11:in `test_should_have_atleast_one_post' /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/testing/setup_and_teardown.rb:33:in `__send__' /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/testing/setup_and_teardown.rb:33:in `run']: Should not be nil as Posts table should have atleast one post. <nil> expected to not be nil. 2 tests, 2 assertions, 1 failures, 0 errors
To see how an error gets reported, here's a test containing an error:
def test_should_report_error # some_undefined_variable is not defined elsewhere in the test case some_undefined_variable assert true end
Now you can see even more output in the console from running the tests:
$ ruby unit/post_test.rb Loaded suite unit/post_test Started FE. Finished in 0.108389 seconds. 1) Failure: test_should_have_atleast_one_post(PostTest) [unit/post_test.rb:11:in `test_should_have_atleast_one_post' /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/testing/setup_and_teardown.rb:33:in `__send__' /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/testing/setup_and_teardown.rb:33:in `run']: Should not be nil as Posts table should have atleast one post. <nil> expected to not be nil. 2) Error: test_should_report_error(PostTest): NameError: undefined local variable or method `some_undefined_variable' for #<PostTest:0x304a7b0> /opt/local/lib/ruby/gems/1.8/gems/actionpack-2.1.1/lib/action_controller/test_process.rb:467:in `method_missing' unit/post_test.rb:15:in `test_should_report_error' /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/testing/setup_and_teardown.rb:33:in `__send__' /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/testing/setup_and_teardown.rb:33:in `run' 3 tests, 2 assertions, 1 failures, 1 errors
Notice the E in the output. It denotes a test with error.
| The execution of each test method stops as soon as any error or a assertion failure is encountered, and the test suite continues with the next method. All test methods are executed in alphabetical order. |
3.2. What to Include in Your Unit Tests
Ideally you would like to include a test for everything which could possibly break. It's a good practice to have at least one test for each of your validations and at least one test for every method in your model.
| Many Rails developers practice test-driven development (TDD), in which the tests are written before the code that they are testing. This is an excellent way to build up a test suite that exercises every part of your application. TDD is beyond the scope of this guide, but one place to start is with 15 TDD steps to create a Rails application. |
3.3. Assertions Available
By now you've caught a glimpse of some of the assertions that are available. Assertions are the worker bees of testing. They are the ones that actually perform the checks to ensure that things are going as planned.
There are a bunch of different types of assertions you can use. Here's the complete list of assertions that ship with test/unit, the testing library used by Rails. The [msg] parameter is an optional string message you can specify to make your test failure messages clearer. It's not required.
| Assertion | Purpose |
|---|---|
| assert( boolean, [msg] ) | Ensures that the object/expression is true. |
| assert_equal( obj1, obj2, [msg] ) | Ensures that obj1 == obj2 is true. |
| assert_not_equal( obj1, obj2, [msg] ) | Ensures that obj1 == obj2 is false. |
| assert_same( obj1, obj2, [msg] ) | Ensures that obj1.equal?(obj2) is true. |
| assert_not_same( obj1, obj2, [msg] ) | Ensures that obj1.equal?(obj2) is false. |
| assert_nil( obj, [msg] ) | Ensures that obj.nil? is true. |
| assert_not_nil( obj, [msg] ) | Ensures that obj.nil? is false. |
| assert_match( regexp, string, [msg] ) | Ensures that a string matches the regular expression. |
| assert_no_match( regexp, string, [msg] ) | Ensures that a string doesn't matches the regular expression. |
| assert_in_delta( expecting, actual, delta, [msg] ) | Ensures that the numbers expecting and actual are within delta of each other. |
| assert_throws( symbol, [msg] ) { block } | Ensures that the given block throws the symbol. |
| assert_raises( exception1, exception2, … ) { block } | Ensures that the given block raises one of the given exceptions. |
| assert_nothing_raised( exception1, exception2, … ) { block } | Ensures that the given block doesn't raise one of the given exceptions. |
| assert_instance_of( class, obj, [msg] ) | Ensures that obj is of the class type. |
| assert_kind_of( class, obj, [msg] ) | Ensures that obj is or descends from class. |
| assert_respond_to( obj, symbol, [msg] ) | Ensures that obj has a method called symbol. |
| assert_operator( obj1, operator, obj2, [msg] ) | Ensures that obj1.operator(obj2) is true. |
| assert_send( array, [msg] ) | Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true. This one is weird eh? |
| flunk( [msg] ) | Ensures failure. This is useful to explicitly mark a test that isn't finished yet. |
Because of the modular nature of the testing framework, it is possible to create your own assertions. In fact, that's exactly what Rails does. It includes some specialized assertions to make your life easier.
| Creating your own assertions is an advanced topic that we won't cover in this tutorial. |
3.4. Rails Specific Assertions
Rails adds some custom assertions of its own to the test/unit framework:
| Assertion | Purpose |
|---|---|
| assert_valid(record) | Ensures that the passed record is valid by Active Record standards and returns any error messages if it is not. |
| assert_difference(expressions, difference = 1, message = nil) {|| …} | Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block. |
| assert_no_difference(expressions, message = nil, &block) | Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block. |
| assert_recognizes(expected_options, path, extras={}, message=nil) | Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options. |
| assert_generates(expected_path, options, defaults={}, extras = {}, message=nil) | Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures. |
| assert_response(type, message = nil) | Asserts that the response comes with a specific status code. You can specify :success to indicate 200, :redirect to indicate 300-399, :missing to indicate 404, or :error to match the 500-599 range |
| assert_redirected_to(options = {}, message=nil) | Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such that assert_redirected_to(:controller ⇒ "weblog") will also match the redirection of redirect_to(:controller ⇒ "weblog", :action ⇒ "show") and so on. |
| assert_template(expected = nil, message=nil) | Asserts that the request was rendered with the appropriate template file. |
You'll see the usage of some of these assertions in the next chapter.
4. Functional Tests for Your Controllers
In Rails, testing the various actions of a single controller is called writing functional tests for that controller. Controllers handle the incoming web requests to your application and eventually respond with a rendered view.
4.1. What to include in your Functional Tests
You should test for things such as:
-
was the web request successful?
-
was the user redirected to the right page?
-
was the user successfully authenticated?
-
was the correct object stored in the response template?
-
was the appropriate message displayed to the user in the view
When you use script/generate to create a controller, it automatically creates a functional test for that controller in test/functional. For example, if you create a post controller:
$ script/generate controller post ... create app/controllers/post_controller.rb create test/functional/post_controller_test.rb ...
Now if you take a look at the file posts_controller_test.rb in the test/functional directory, you should see:
require 'test_helper' class PostsControllerTest < ActionController::TestCase # Replace this with your real tests. def test_truth assert true end end
Of course, you need to replace the simple assertion with real testing. Here's a starting example of a functional test:
def test_should_get_index get :index assert_response :success assert_not_nil assigns(:posts) end
In the test_should_get_index test, Rails simulates a request on the action called index, making sure the request was successful and also ensuring that it assigns a valid posts instance variable.
The get method kicks off the web request and populates the results into the response. It accepts 4 arguments:
-
The action of the controller you are requesting. This can be in the form of a string or a symbol.
-
An optional hash of request parameters to pass into the action (eg. query string parameters or post variables).
-
An optional hash of session variables to pass along with the request.
-
An optional hash of flash values.
Example: Calling the :show action, passing an id of 12 as the params and setting a user_id of 5 in the session:
get(:show, {'id' => "12"}, {'user_id' => 5})
Another example: Calling the :view action, passing an id of 12 as the params, this time with no session, but with a flash message.
get(:view, {'id' => '12'}, nil, {'message' => 'booya!'})
4.2. Available Request Types for Functional Tests===
If you're familiar with the HTTP protocol, you'll know that get is a type of request. There are 5 request types supported in Rails functional tests:
-
get
-
post
-
put
-
head
-
delete
All of request types are methods that you can use, however, you'll probably end up using the first two more often than the others.
4.3. The 4 Hashes of the Apocalypse
After a request has been made by using one of the 5 methods (get, post, etc.) and processed, you will have 4 Hash objects ready for use:
-
assigns - Any objects that are stored as instance variables in actions for use in views.
-
cookies - Any cookies that are set.
-
flash - Any objects living in the flash.
-
session - Any object living in session variables.
As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for assigns. For example:
flash["gordon"] flash[:gordon] session["shmession"] session[:shmession] cookies["are_good_for_u"] cookies[:are_good_for_u] # Because you can't use assigns[:something] for historical reasons: assigns["something"] assigns(:something)
4.4. Instance Variables Available
You also have access to three instance variables in your functional tests:
-
@controller - The controller processing the request
-
@request - The request
-
@response - The response
4.5. A Fuller Functional Test Example
Here's another example that uses flash, assert_redirected_to, and assert_difference:
def test_should_create_post assert_difference('Post.count') do post :create, :post => { :title => 'Hi', :body => 'This is my first post.'} end assert_redirected_to post_path(assigns(:post)) assert_equal 'Post was successfully created.', flash[:notice] end
4.6. Testing Views
Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax.
| You may find references to assert_tag in other documentation, but this is now deprecated in favor of assert_select. |
There are two forms of assert_select:
assert_select(selector, [equality], [message])` ensures that the equality condition is met on the selected elements through the selector. The selector may be a CSS selector expression (String), an expression with substitution values, or an HTML::Selector object.
assert_select(element, selector, [equality], [message]) ensures that the equality condition is met on all the selected elements through the selector starting from the element (instance of HTML::Node) and its descendants.
For example, you could verify the contents on the title element in your response with:
assert_select 'title', "Welcome to Rails Testing Guide"
You can also use nested assert_select blocks. In this case the inner assert_select will run the assertion on each element selected by the outer assert_select block:
assert_select 'ul.navigation' do assert_select 'li.menu_item' end
The assert_select assertion is quite powerful. For more advanced usage, refer to its documentation.
4.6.1. Additional View-based Assertions
There are more assertions that are primarily used in testing views:
| Assertion | Purpose |
|---|---|
| assert_select_email | Allows you to make assertions on the body of an e-mail. |
| assert_select_rjs | Allows you to make assertions on RJS response. assert_select_rjs has variants which allow you to narrow down on the updated element or even a particular operation on an element. |
| assert_select_encoded | Allows you to make assertions on encoded HTML. It does this by un-encoding the contents of each element and then calling the block with all the un-encoded elements. |
| css_select(selector) or css_select(element, selector) | Returns an array of all the elements selected by the selector. In the second variant it first matches the base element and tries to match the selector expression on any of its children. If there are no matches both variants return an empty array. |
Here's an example of using assert_select_email:
assert_select_email do assert_select 'small', 'Please click the "Unsubscribe" link if you want to opt-out.' end
5. Integration Testing
Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application.
Unlike Unit and Functional tests, integration tests have to be explicitly created under the test/integration folder within your application. Rails provides a generator to create an integration test skeleton for you.
$ script/generate integration_test user_flows exists test/integration/ create test/integration/user_flows_test.rb
Here's what a freshly-generated integration test looks like:
require 'test_helper' class UserFlowsTest < ActionController::IntegrationTest # fixtures :your, :models # Replace this with your real tests. def test_truth assert true end end
Integration tests inherit from ActionController::IntegrationTest. This makes available some additional helpers to use in your integration tests. Also you need to explicitly include the fixtures to be made available to the test.
5.1. Helpers Available for Integration tests
In addition to the standard testing helpers, there are some additional helpers available to integration tests:
| Helper | Purpose |
|---|---|
| https? | Returns true if the session is mimicking a secure HTTPS request. |
| https! | Allows you to mimic a secure HTTPS request. |
| host! | Allows you to set the host name to use in the next request. |
| redirect? | Returns true if the last request was a redirect. |
| follow_redirect! | Follows a single redirect response. |
| request_via_redirect(http_method, path, [parameters], [headers]) | Allows you to make an HTTP request and follow any subsequent redirects. |
| post_via_redirect(path, [parameters], [headers]) | Allows you to make an HTTP POST request and follow any subsequent redirects. |
| get_via_redirect(path, [parameters], [headers]) | Allows you to make an HTTP GET request and follow any subsequent redirects. |
| put_via_redirect(path, [parameters], [headers]) | Allows you to make an HTTP PUT request and follow any subsequent redirects. |
| delete_via_redirect(path, [parameters], [headers]) | Allows you to make an HTTP DELETE request and follow any subsequent redirects. |
| open_session | Opens a new session instance. |
5.2. Integration Testing Examples
A simple integration test that exercises multiple controllers:
require 'test_helper' class UserFlowsTest < ActionController::IntegrationTest fixtures :users def test_login_and_browse_site # login via https https! get "/login" assert_response :success post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password assert_equal '/welcome', path assert_equal 'Welcome avs!', flash[:notice] https!(false) get "/posts/all" assert_response :success assert assigns(:products) end end
As you can see the integration test involves multiple controllers and exercises the entire stack from database to dispatcher. In addition you can have multiple session instances open simultaneously in a test and extend those instances with assertion methods to create a very powerful testing DSL (domain-specific language) just for your application.
Here's an example of multiple sessions and custom DSL in an integration test
require 'test_helper' class UserFlowsTest < ActionController::IntegrationTest fixtures :users def test_login_and_browse_site # User avs logs in avs = login(:avs) # User guest logs in guest = login(:guest) # Both are now available in different sessions assert_equal 'Welcome avs!', avs.flash[:notice] assert_equal 'Welcome guest!', guest.flash[:notice] # User avs can browse site avs.browses_site # User guest can browse site aswell guest.browses_site # Continue with other assertions end private module CustomDsl def browses_site get "/products/all" assert_response :success assert assigns(:products) end end def login(user) open_session do |sess| sess.extend(CustomDsl) u = users(user) sess.https! sess.post "/login", :username => u.username, :password => u.password assert_equal '/welcome', path sess.https!(false) end end end
6. Testing Your Mailers
Testing mailer classes requires some specific tools to do a thorough job.
6.1. Keeping the Postman in Check
Your ActionMailer classes — like every other part of your Rails application — should be tested to ensure that it is working as expected.
The goals of testing your ActionMailer classes are to ensure that:
-
emails are being processed (created and sent)
-
the email content is correct (subject, sender, body, etc)
-
the right emails are being sent at the right times
6.1.1. From All Sides
There are two aspects of testing your mailer, the unit tests and the functional tests. In the unit tests, you run the mailer in isolation with tightly controlled inputs and compare the output to a knownvalue (a fixture — yay! more fixtures!). In the functional tests you don't so much test the minute details produced by the mailer Instead we test that our controllers and models are using the mailer in the right way. You test to prove that the right email was sent at the right time.
6.2. Unit Testing
In order to test that your mailer is working as expected, you can use unit tests to compare the actual results of the mailer with pre-written examples of what should be produced.
6.2.1. Revenge of the Fixtures
For the purposes of unit testing a mailer, fixtures are used to provide an example of how the output should look. Because these are example emails, and not Active Record data like the other fixtures, they are kept in their own subdirectory apart from the other fixtures. The name of the directory within test/fixtures directly corresponds to the name of the mailer. So, for a mailer named UserMailer, the fixtures should reside in test/fixtures/user_mailer directory.
When you generated your mailer, the generator creates stub fixtures for each of the mailers actions. If you didn't use the generator you'll have to make those files yourself.
6.2.2. The Basic Test case
Here's a unit test to test a mailer named UserMailer whose action invite is used to send an invitation to a friend. It is an adapted version of the base test created by the generator for an invite action.
require 'test_helper' class UserMailerTest < ActionMailer::TestCase tests UserMailer def test_invite @expected.from =<EMAIL_ADDRESS>@expected.to =<EMAIL_ADDRESS>@expected.subject = "You have been invited by<EMAIL_ADDRESS>@expected.body = read_fixture('invite') @expected.date = Time.now assert_equal @expected.encoded<EMAIL_ADDRESS><EMAIL_ADDRESS>@expected.date).encoded end end
In this test, @expected is an instance of TMail::Mail that you can use in your tests. It is defined in ActionMailer::TestCase. The test above uses @expected to construct an email, which it then asserts with email created by the custom mailer. The invite fixture is the body of the email and is used as the sample content to assert against. The helper read_fixture is used to read in the content from this file.
Here's the content of the invite fixture:
Hi<EMAIL_ADDRESS>You have been invited. Cheers!
This is the right time to understand a little more about writing tests for your mailers. The line ActionMailer::Base.delivery_method = :test in config/environments/test.rb sets the delivery method to test mode so that email will not actually be delivered (useful to avoid spamming your users while testing) but instead it will be appended to an array (ActionMailer::Base.deliveries).
However often in unit tests, mails will not actually be sent, simply constructed, as in the example above, where the precise content of the email is checked against what it should be.
6.3. Functional Testing
Functional testing for mailers involves more than just checking that the email body, recipients and so forth are correct. In functional mail tests you call the mail deliver methods and check that the appropriate emails have been appended to the delivery list. It is fairly safe to assume that the deliver methods themselves do their job You are probably more interested in is whether your own business logic is sending emails when you expect them to got out. For example, you can check that the invite friend operation is sending an email appropriately:
require 'test_helper' class UserControllerTest < ActionController::TestCase def test_invite_friend assert_difference 'ActionMailer::Base.deliveries.size', +1 do post :invite_friend, :email =><EMAIL_ADDRESS>end invite_email = ActionMailer::Base.deliveries.first assert_equal invite_email.subject, "You have been invited by<EMAIL_ADDRESS>assert_equal invite_email.to[0]<EMAIL_ADDRESS>assert_match /Hi<EMAIL_ADDRESS>invite_email.body end end
7. Rake Tasks for Testing
You don't need to set up and run your tests by hand on a test-by-test basis. Rails comes with a number of rake tasks to help in testing. The table below lists all rake tasks that come along in the default Rakefile when you initiate a Rail project.
--------------------------------`---------------------------------------------------- Tasks Description
+rake test+ Runs all unit, functional and integration tests. You can also simply run +rake+ as the _test_ target is the default. +rake test:units+ Runs all the unit tests from +test/unit+ +rake test:functionals+ Runs all the functional tests from +test/functional+ +rake test:integration+ Runs all the integration tests from +test/integration+ +rake test:recent+ Tests recent changes +rake test:uncommitted+ Runs all the tests which are uncommitted. Only supports Subversion +rake test:plugins+ Run all the plugin tests from +vendor/plugins/*/**/test+ (or specify with +PLUGIN=_name_+) +rake db:test:clone+ Recreate the test database from the current environment's database schema +rake db:test:clone_structure+ Recreate the test databases from the development structure +rake db:test:load+ Recreate the test database from the current +schema.rb+ +rake db:test:prepare+ Check for pending migrations and load the test schema +rake db:test:purge+ Empty the test database.
| You can see all these rake task and their descriptions by running rake —tasks —describe |
8. Other Testing Approaches
The built-in test/unit based testing is not the only way to test Rails applications. Rails developers have come up with a wide variety of other approaches and aids for testing, including:
-
NullDB, a way to speed up testing by avoiding database use.
-
Factory Girl, as replacement for fixtures.
-
Shoulda, an extension to test/unit with additional helpers, macros, and assertions.
-
link: RSpec, a behavior-driven development framework
9. Changelog
-
October 14, 2008: Edit and formatting pass by Mike Gunderloy (not yet approved for publication)
-
October 12, 2008: First draft by Akashay Surve (not yet approved for publication)


WebRTC Demo
Username:
Connect
Online users
Call
Hangup
Share Screen
Stop Sharing
Send File
Signaling Log
Chat
Name:
Message:
Send


Move Calculator
Measure travel distance and turns precisely for your robot. Support for geared robots coming soon!
wheel diameter
wheel circumference
Calculate Turns
distance
wheel distance
turn
Rotations:
Degrees:
Note: All values must come from one unit of measure.


| Path: | lib/zip/ziprequire.rb |
| Last Update: | Mon Aug 29 13:09:01 -0700 2011 |
With ziprequire you can load ruby modules from a zip file. This means ruby‘s module include path can include zip-files.
The following example creates a zip file with a single entry log/simplelog.rb that contains a single function simpleLog:
require 'zip/zipfilesystem' Zip::ZipFile.open("my.zip", true) { |zf| zf.file.open("log/simplelog.rb", "w") { |f| f.puts "def simpleLog(v)" f.puts ' Kernel.puts "INFO: #{v}"' f.puts "end" } }
To use the ruby module stored in the zip archive simply require zip/ziprequire and include the my.zip zip file in the module search path. The following command shows one way to do this:
ruby -rzip/ziprequire -Imy.zip -e " require 'log/simplelog'; simpleLog 'Hello world' "


Find property information
Use this service to get information related to any property (eg price paid, council tax band) in England and Wales.
Use this service to get information related to any property (eg price paid, council tax band) in England and Wales.


biomass mass species body &; moths abundance OpenUrl forewing using data model measured length dry samples moth relationship plotted relationships study trends changes declines families estimated predicted historical predictive richness CrossRef individual (e.g. Insect RIS insect mean British Heslington Table approach biomass, change sample Conservation, Fig. Fox, However, decline family linear sampled species, time variation -year Biological View community dataset estimate field long-term models parameters tested used Ecological Science Web absolute captured data, empirical estimates moths. period point potential slope Download M.S. Moths Parsons, based collected datasets effects expected intercept light moths, number possible predict significance significant use <; (mg) (mg); A.J. Biology, García-Barros, Geometridae University conservation drivers given including insects length, lengths model’s overall shown significantly spatial statistical studies total trap (i.e. Conservation Ellis, Entomology, Erebidae, Langevelde Rothamsted S). Sánchez-Bayo Townsend, Wyckhuys, York annual calculated composition correlated dataset. datasets, declined difference family, important individuals large masses new night nocturnal range rank recorded refined site size species- specimens test trait van (Crambidae, (Fig. (Table (with Field Figure Fox Garcia, Hallmann J.M. Moth National Open Predicted Scheme Spearman’s Therefore, Waring allow artificial associated available axes, blue colour coloured communities compared data-hide-link-title=""> data-icon-position="" dataset, dimorphism error explained figure greater guides horizontal identification identified include included indicated information investigate length) line line, logarithmic measurements mixed-effects non-parametric opportunities points provide questions random recording sample-level scales sexual showing single solid speciose standard strength study; substantial sufficient tab taxonomic temporal testing variable


{% extends 'base.html' %} {% block pagetitle %}Brian R. Bondy - Super User expected age by tag list{% endblock %} {% block title %} Super User expected age by tag list{% endblock %} {% block subtitle %}Calculated by using the expected value for the age each answer comes from{% endblock %} {% block main_content %}
This list contains the expected age per tag from the the Super User site, sorted by expected age.
The list was generated with the Super User April 2011 data dump on 4/25/2011 10:48:25 PM.
The creator of this list is Brian R. Bondy: Blog, Twitter, StackOverflow.
Please see the following link for other lists.


Welcome to Chubby Otter
This is the testing ground for all our crazy ideas and things we want to practice.
Home
Hostile UX
Frustrating Forms
Combative Captcha
About
Contributors
Elliott Jones
GitHub:
JonesElliott
Sam Foster
GitHub:
Samwise2980


We are proud to announce the release of the Third Edition of Semantic Web for the Working Ontologist. It has been 8 years since the release of the second edition. There are a number of new features in this edition:
The most noticeable to you since you are reading this is the website. Now that the Semantic Web is a reality, we have hosted the data from the book on this website as a set of semantic web resources. In particular:
- Every data set in the book is indexed on this website, and available for download.
- Furthermore, the data sets are hosted at data.world, which provides services for data like the services that GitHub provides for code. This means that the queries are also hosted here. You can run the queries, and even edit them. You will need a login to data.world to do this, but that is easily done if you have an identity on any of several networks.
- Every resource in the data sets is available according to the follow-your-nose pattern. Since the sample URIs in the book are "hash uris" this means that a server can't provide just the information about a single resource; so you'll get infromation about a set of related resources.
New Material
The third edition includes some new material not found in the second edition. This includes:
- A new chapter on Linked Data protocols. The Semantic Web is fully integrated into the web infrastructure, and there are clear protocols for how to use it effectively. (Chapter 5)
- SHACL - the Shapes language for RDF. SHACL complements the modeling capabilities of OWL by providing closed-world defintions of expectations of RDF resources.
- Schema.org - one of the most successful Semantic Web applications. Earlier examples from Good Relations are now absorbed into Schema.org
- FIBO - the Financial Industry Business Ontology. One of the most advanced uses of OWL in industry today.
- BridgeDB - a powerful link set mapping concepts in life sciences across various data sources.
- wikidata, dbpedia, and other powerful linked data sources
Many familiar examples have been updated to reflect recent work. AGROVOC, QUDT, and data.gov have all progressed since the second edition; the new features are reflected in the examples. All of the examples from these sources are inclued in the queries on this web site; a snapshot of each of these data sets is included in the data on this site (and often, we simply link to the most recent publication of these things, like FIBO and dbpedia).
In our practice in academia and industry, we are more sophisticated about what works and what doesn't work in building a semantic web system. The advice chapters at the end of the book are a good deal more mature than they were in 2012.
And we saved the biggest thing for last - we welcome Fabien Gandon as a new author for Semantic Web for the Working Ontologist. He brings a strong instinct for Web Science and linked data to the project; we are thrilled to have his contribution.


Personal Summary
I am a motivated and determined individual who is disciplined and has the desire to succeed within the IT environment. Possessing good level of knowledge of the development of web applications/Mobile application and scripts using PHP programming language and MySQL. Recently completed the final year in Computing at Greenwich university with a First-class honours (1st) and looking for a suitable developer position with an ambitious & exciting company.
Academic Qualifications
BA (Hons) Computing
Greenwich university 2015-2016
Computing FdSc
Bexley College 2013-2015
Work Experience
Junior Stockbroker
- First call to new prospective clients
- Second call follow up calls to prospective clients
- Learn about CFDs
Retail Assistant
- Approching clients
- Providing information
Areas of Expertise
- PHP
- CSS
- HTML
- JavaScript
Personal Skills
- Assertive
- Listening
- Confident


from when: {{initial_post.from_when}}
category title: {{initial_post.category_title}}
description: {{initial_post.description}}
created_at: {{initial_post.created_at}}
first_name: {{initial_post.first_name}}


Give your taste-buds a taste of paradise with our variety of toppings today at an affordable price.
Name:
Email:
Phone:
Address:
Pizza:
Quantity:
From Kshs. 950+
From Kshs. 550+
From Kshs. 450+
From Kshs. 850+
From Kshs. 650+
From Kshs. 750+
copyright © 2021 All rights reserved


|
App Engine Python SDK
v1.6.9 rev.445
The Python runtime is available as an experimental Preview feature.
|
Public Member Functions | |
| def | substring |
| def | LT |
| def | getLine |
| def | setLine |
| def | getCharPositionInLine |
| def | setCharPositionInLine |
| Public Member Functions inherited from google.appengine._internal.antlr3.streams.IntStream | |
| def | consume |
| def | LA |
| def | mark |
| def | index |
| def | rewind |
| def | release |
| def | seek |
| def | size |
| def | getSourceName |
Static Public Attributes | |
| int | EOF = -1 |
@brief A source of characters for an ANTLR lexer. This is an abstract class that must be implemented by a subclass.
| def google.appengine._internal.antlr3.streams.CharStream.getCharPositionInLine | ( | self | ) |
The index of the character relative to the beginning of the line 0..n-1
| def google.appengine._internal.antlr3.streams.CharStream.getLine | ( | self | ) |
ANTLR tracks the line information automatically
| def google.appengine._internal.antlr3.streams.CharStream.LT | ( | self, | |
| i | |||
| ) |
Get the ith character of lookahead. This is the same usually as LA(i). This will be used for labels in the generated lexer code. I'd prefer to return a char here type-wise, but it's probably better to be 32-bit clean and be consistent with LA.
| def google.appengine._internal.antlr3.streams.CharStream.setLine | ( | self, | |
| line | |||
| ) |
Because this stream can rewind, we need to be able to reset the line
| def google.appengine._internal.antlr3.streams.CharStream.substring | ( | self, | |
| start, | |||
| stop | |||
| ) |
For infinite streams, you don't need this; primarily I'm providing a useful interface for action code. Just make sure actions don't use this on streams that don't support it.


From now, heart rate based activities have their stress scores processed with
Heart Rate Stress Score
(HRSS) method. They were previously processed using the
Training Impulse
(TRIMP) method only.
The
HRSS method has been added over
TRIMP because:
-
HRSS scores are scaled to be use with Training Zones. TRIMP had a scale missmatch
with Training Zones.
-
HRSS scores can be directly compared to Cycling Power Stress Scores (PSS). They use same
referential or scale.
-
HRSS scores can be directly compared to Swimming Stress Scores (SSS). They also use same
referential or scale.
warning
You should
setup your own Lactate Threshold Heart Rate (LTHR) in
athlete settings
for best results. (
LTHR is basically the latest best average heart rate you can maintain for up to an
hour.)
However you can still enable back TRIMP as default heart rate stress score calculation
method in the feature settings by clicking the
settings
icon.
And a new fitness trend guide is accessible from
help_outline
icon. Reading this guide is also strongly recommended.
Don't show this message again


small survey ... how do you think, how many people used our komodo-qt in everyday life? question related to upcoming changes since 1.000.000 block ... currently komodo-qt didn't have needed changes in sources for monthly interest claim support and few other things. we didn't see much interest from the community to this wallet. so, the main question is - should we continue to support it? if nobody uses it, should we continue to work on it?(edited)
ComputerGenie28-Jun-18 12:36 AM
Unless Agama is planed to eventually have advanced features, I think the qt wallet is highly necessary; however, I could just be biased because I use it daily
As to the 2nd part, community interest could have to do with presentation. 99% of the time all people hear is Agama. Granted, it's a flagship product, but I don't think most people even know there is a qt wallet
1
jorian28-Jun-18 09:53 AM
never used it, but i think QT is underpromoted on KMD platform since Agama is the wallet to rule them all
once on the KMD platform, chances are you want an asset or two, and that will want you to go to Agama
ComputerGenie28-Jun-18 11:29 AM
"since Agama is the wallet to rule them all"
Until Agama has any real coin features, I'll continue to not use it.
imo, Agama is the granny wallet and QT is the wallet for people that actually use currency.
SHossain28-Jun-18 11:33 AM
@ComputerGenie you are in the right channel
ComputerGenie28-Jun-18 11:33 AM
I do that every now and then
1
jorian28-Jun-18 12:08 PM
well i can use a currency using Agama
define use
ComputerGenie28-Jun-18 12:24 PM
maybe "use" is too strong of a word and I should have said "maintain personal control of"?
Unless I've just missed something, Agama lacks :
the ability to send multiple payments at once
the ability to control fee expenses
any way to manage UTXOs manually
and
any way to even know what UTXOs you have.

jorian28-Jun-18 12:29 PM
good analogy, i think you're right. but it's the easy solution what most people want. If you buy a 23.49$ coffee and all you have are lots of quarters and dimes, then most people are lazy as fuck and rather shove it, yes.
the cashier is a computer after all
ComputerGenie28-Jun-18 12:32 PM
OK, the flip side to that is:
If you want to spend 9 KMD and you have UTXOs of 10, 10, 3, 3, 3, 3, 3, 3, and 0.0001 then agama will bust up your reward 10 and leave you with 10, 3, 3, 3, 3, 3, 3, 0.9999, and 0.0001
because, bitcoin
jorian28-Jun-18 12:33 PM
yeah, who cares. :troll:
but anyways, you use QT, i think most of the advanced users use the CLI
and in that way, Agama is really the granny solution
and that's not bad
ComputerGenie28-Jun-18 12:34 PM
I'm not saying Agama's not a good product or that it's not good for many folks; I'm just saying that I think QT has a place and there are a lot more folks like me out there (that perhaps haven't even come to Komodo yet)(edited)
jorian28-Jun-18 12:34 PM
if you want more control, you need to do a little more
ComputerGenie28-Jun-18 12:36 PM
"but anyways, you use QT, i think most of the advanced users use the CLI"
tbh, I use QT on my win box only and cli on nix boxes
Decker28-Jun-18 02:26 PM
What about me - i'm using QT on both platforms: WIndows and Ubuntu, it's very convenient ... and Coin Control Features are "unique". I can simply select an utxo from which i want to send coins. Agama doesn't allow this, and from cli - this is a problem too. Because no utxo field in sendtoaddress or other cli commands. In CLI i just can do lockunspent to prevent few utxos from being spended. But i can't select an utxo from which i wish to spend from CLI ... and this is not comfortable.(edited)
2
PTYX28-Jun-18 02:27 PM
I like QT coin control
ComputerGenie28-Jun-18 02:27 PM
Seems you answered your own question there; yes, we need it
Decker28-Jun-18 02:27 PM
But Qt have other problems ... if you have 20000 utxo with 0.0001 KMD in your wallet - GUI will hang for a couple of minutes to display it )
That's why it's not recommended to use wallet.dat with very high number of utxos with Qt.
Btw, today i invited @Ocean in this chat ...(edited)
ComputerGenie28-Jun-18 02:30 PM
The hang and lack of multi-select are negatives, but the hang is more inherent in the core than the GUI (I think)
alternatively, don't mine 20k blocks before you consolidate (edited)
pbca2601-Jul-18 04:44 PM
mos of the features you desire are not needed for regular users
if we loose one computergenie to qt wallet and gain more average joes in agama i say that's a solid win
no one in sane mind is going to work through numbers to save on some dust fee amounts as well as messing with individual utxos
people wanted a somewhat grama friendly product so here you have it
i like qt wallets for their speed and advanced features for hardcore folks
ComputerGenie01-Jul-18 04:46 PM
Yes, @pbca26, because what sane person would want to send out 2+ payments at once rather than paying double tx fees (edited)
pbca2601-Jul-18 04:46 PM
how many people need to send 2 or more payments?
ComputerGenie01-Jul-18 04:47 PM
When a crypto is actually used as a currency: many
I get going for mass appeal; I don't get the notion of "fek real use cases we love Granny"
pbca2601-Jul-18 04:49 PM
well most folks want grandma friendly
they don't need coinage control or mass payments
anyhow all these features are on my todo list but they come last on it
ComputerGenie01-Jul-18 04:50 PM
If you were paying your monthly bills and had fees asigned to amount of payments, would you opt for paying extra fees and making extra payments or opt for less fees and only having to make 1 payment?
pbca2601-Jul-18 04:50 PM
are you paying your monthly bills in kmd?
ComputerGenie01-Jul-18 04:50 PM
the hope is someday
pbca2601-Jul-18 04:51 PM
lol
ComputerGenie01-Jul-18 04:51 PM
if we're not in crypto to use is as a currency, then wtf are we doing
pbca2601-Jul-18 04:51 PM
when the day finally comes i'll add it
ComputerGenie01-Jul-18 04:52 PM
keep in mind that this fee argument is coming from a guy that makes his living off of fees
professionally, I hope no one ever pays less fees
personally, I find limiting options to be limiting
pbca2601-Jul-18 04:54 PM
for your own good :)
not w/o a reason
ComputerGenie01-Jul-18 04:54 PM
"Limiting your options for your own good"
Didn't they try that in 1940s Germany?(edited)
pbca2601-Jul-18 04:56 PM
lets not succumb into history/politics discussion
your consideration is noted
ComputerGenie01-Jul-18 04:58 PM
That was more sarcasm than political, but my point is that while I can see keeping Agama as a flagship product, I think that making it the sole focus is a horrible idea
By extension, it's the same as abandoning BarterDEX and only promoting HyperDEX(edited)
If marketing is pushing Komodo as an "end-to-end blockchain technology provider", it's counter to that to say that apps with extended features are "insane"
pbca2601-Jul-18 05:03 PM
all products deserve focus
but i'm not sure how agama is related to any pr
there's no pr and never was, random tweets and posts don't make it marketing
ComputerGenie01-Jul-18 05:04 PM
scroll through the marketing channel (or most any of them) and count the team references to "Agama" and count the total references by everyone (not counting me) for "QT" or "Ocean"(edited)
"...seems like they forgot about Dre...."
In fact, if you read #komodo-team from yesterday and don't get the sense that Audo is all about pr for Agama (where wallets are concerned), then I'll never speak of wallets again
PTYX01-Jul-18 05:29 PM
I don't see why we can have the best of both worlds and have QT for the technically inclined and Agama as a user friendly wallet
ComputerGenie01-Jul-18 05:31 PM
that's what I'm saying
or even add an overlay for the raws to Agama and have it all in one
While I love the technical aspects of Ocean being 1 of only 2 equihash QT wallets, if Agama had actual currency features then this would be a different conversation
It's hard to be an "end-to-end blockchain technology provider" and cut out promotion of a given x feature of tech
And, while it's technically, grammatically true that "Agama doesn't get pr", it's 99.9999999% the only option offered or discussed and I'd literally bet some KMD that about the same percentage of users don't even know that Ocean exists
PTYX01-Jul-18 05:45 PM
Does coin control work in spv?(edited)
ComputerGenie01-Jul-18 05:53 PM
same as in native: raw transactions (like mm uses)
and to step into my condescending shoes for a moment:
Not counting electron, what tech is in Agama besides a webpage and a bit of ajax?(edited)
PTYX01-Jul-18 07:08 PM
Your feature request is added to the wishlist. If it's so simple then make the changes and PR. If not, then we wait for the person who tackles the feature wishlist by priority.
ComputerGenie01-Jul-18 07:15 PM
"If it's so simple then make the changes and PR."
The flip side to that is:
"Why would I spend time coding a feature that already exists in a hugely over-looked, and under-promoted, app already?"
combined with:
"If I didn't suck at graphic design, I likely would have done so long before the Ocean wallet existed"
xRobeSx01-Jul-18 08:28 PM
I have to add in, there are tons of people that have experience with QT wallets, so it would be nice to have that experience available with KMD. I use Komodo-Ocean-QT on one machine, so I would like to see it continue if possible @Decker
The missing from KMD site has been raised - i said "at latest v2.0 website" and the task has been added to the board by Steve - so it's known at the highest level
@Steve Lee in case you want some references for Ocean's relevance, scroll up
Decker03-Jul-18 04:05 AM
We will try to update current version of Komodo-Qt to latest codebase (mean master of komodod) till half of July. Me or Ocean will inform community about a progress here.
Nice to hear that our work is important for community.
1
3
jl777c03-Jul-18 05:20 AM
I am delaying updating master for now. but beta will become master prior to height 1000000
Decker03-Jul-18 05:40 AM
ohhh ... this will be too hard, i think, to import all current beta changes to komodo-qt ... komodo-qt and komodod is unmergable, so, updating komodo-qt it not just git merge ... it's a hard work to analyze every (!) commit for compatability with komodo-qt. if you just merge beta komodod into master - i think we don't have time to import all changes. because currently, as i remember, don't contain anything about new assetchains keys and other things. also, as i remember, dev and beta branches have some changes in library usage ... it seems to me it will like a pain ...
importing in komodo-qt current commits from master - is a one work, but if master will be merged with beta - it's a totally different and more harder work.
jl777c03-Jul-18 06:00 AM
ok, then make the version compatible with master for now. that should work for KMD, just wont work with the new CC enabled chains or chains using new ac options
Decker03-Jul-18 06:21 AM
yes, this was initial plan ... make komodo-qt compatible with current master.
BlackJesus03-Jul-18 04:24 PM
@Decker do you think it would be possible to take the komodo ocean QT and implement the same fix BCH had for ledger through our QT as they did for electron cash
I've been writing with Fyookball to negotiate an electron Komodo wallet. They are now integrating ledger and I think it's worth pursuing a pure fork.
He is open to collaboration.
It would probably be easier to take the BTCP electrum wallet, fork it to Komodo and then apply the ledger changes to the wallet if it doesn't break anything.(edited)


Time Made Visible
Connecting
Home
Settings
Console
Wifi
Video
Server
Camera
On
Off
Auto
Speed
Slow
Medium
Fast
|
Configuration
Save & Restart TMV
Save
Reload
Zoom
Zoom
×
Console
Services
Journal
Files
About
PiJuice
Restart HW
Shutdown HW
Cancel
Wifi Settings
Save
Restart WiFi
Reload
Wifi Tools
Scan
Info
Video Preview
Reload