Tuesday, April 17, 2012
How to limit the number of records returned by mysqldump
How to restrict the size of mysqldump?
mysqldump --where="true LIMIT 1000" -u user-name -p db-name > exported-data.sql
mysqldump --where="true LIMIT 1000" -u user-name -p db-name > exported-data.sql
How to list all the loaded gems on a server
Open a Rails console and type:
$:.each do |x|
p x
end;
p "hi"
$:.each do |x|
p x
end;
p "hi"
$: variable contains the list of all gems loaded into the system. I am suppressing the output of array of those gems by doing ; p "hi" after the end.
Monday, April 16, 2012
How to convert ppk file to normal ssh key in Ubuntu 10.04
sudo apt-get install putty-tools
puttygen your_file.ppk -O private-openssh -o new_file_name
puttygen your_file.ppk -O private-openssh -o new_file_name
scp permission denied publickey
How to copy a file from a remote Ubuntu server to your machine using scp and private key
scp -i /path/to/your_private_key_file user@your_host_or_ip:/path/on/the/remote/machine/file_name .
This will copy file_name to current directory in your local machine
scp -i /path/to/your_private_key_file user@your_host_or_ip:/path/on/the/remote/machine/file_name .
This will copy file_name to current directory in your local machine
How to install mysql gem on Ubuntu 10.04
sudo apt-get install mysql-server mysql-client sudo apt-get install libmysql-ruby libmysqlclient-dev sudo gem install mysql
Install mysql database connector by running the above commands.
How to install Nokogiri on Ubuntu
libxml2 is missing error message is due to missing libraries. Install the pre-requisite library with:
sudo apt-get install libxslt-dev libxml2-devHow to install curb gem on Ubuntu 10.04
sudo apt-get install libcurl3 libcurl3-gnutls libcurl4-openssl-dev
How to install bson_ext on Ubuntu 10.04
Using Bundler 1.1.3 for some reason does not work. Solution:
sudo gem install bson_ext -v=1.0.1
installs the gem.
sudo gem install bson_ext -v=1.0.1
installs the gem.
How to ssh using a given private key
ssh -i /path/to/your_private_key_file user-name@your-ip-address-here
Friday, April 13, 2012
It is recommended that your private key files are NOT accessible by others
I was getting this error : Permissions 0644 for '/home/bparanj/Downloads/my-file.ssh' are too open. when I was ssh ing into a box.
Solution:
sudo chmod 600 your-private-key.ssh
Monday, April 09, 2012
Rails Recipes 3rd Edition
The recipe: Focus Your Tests with Mocking and Stubbing show how to use stubs and mocks. It violates one of the testing best practices. DO NOT mock external services. Why? Because you cannot drive the design of a third party library. For a good discussion on this topic read the "Growing Object Oriented Software Guided by Tests".
I scanned through the book, I was a bit disappointed. Lot of the recipes are just from the old book.
I scanned through the book, I was a bit disappointed. Lot of the recipes are just from the old book.
Saturday, March 17, 2012
WARNING: 'require 'rake/rdoctask'' is deprecated. Please use 'require 'rdoc/task' (in RDoc 2.4.2+)' instead. WARNING: 'require 'rake/rdoctask'' is deprecated. Please use 'require 'rdoc/task' (in RDoc 2.4.2+)' instead
Include rdoc in the Gemfile :
group :development, :test do
gem 'rcov'
gem "rdoc", '~> 3.12'
end
Run bundle install.
group :development, :test do
gem 'rcov'
gem "rdoc", '~> 3.12'
end
Run bundle install.
Tuesday, March 13, 2012
Using Stubs with Test Spy in Ruby
While I was working on my super stealth product of my company - Affiliate Tracking system, I came across a problem during testing. I had to test the cookie setting logic of my controllers. It was straightforward to test that the cookie was set for the happy path. For the alternative scenario it became tricky to test because RSpec and Rails framework did not play that well together. I even read Devise Rails plugin code to see how Jose Valim handled cookie related problems during testing. No luck. One solution I found was on Stackoverflow. How do I test cookie expiry?
This technique is a great example of Test Spy described in Gerard Mezos book xUnit Test Patterns. Basically, you install a spy and check the results collected by the test spy in the verification phase. In this case the Hash is the Test Spy that collects data. See how the stub is used to install the spy in the SUT? It overcomes the problems and isolates the SUT from the Rails framework and allows the code to be tested easily.
In my TDD bootcamps, the topic on Stubs and Mocks generates lot of discussion. To clear confusion that surrounds the stubs and mocks, I would state : Read Martin Fowler's paper on Mocks Aren't Stubs, Stub can never fail your test, only mocks can fail your test. Using stubs in combination with a spy like this makes stubs seem like they can in fact fail your test. But only the data collected by the Test Spy decides whether the test passes or not. So the stub's main purpose is to just isolate the production code from Rails framework and allow access to the internal state of the SUT where there is no direct way to access it.
# app/controllers/widget_controller.rb
...
def index
cookies[:expiring_cookie] = { :value => 'All that we see or seem...',
:expires => 1.hour.from_now }
end
...
# spec/controllers/widget_controller_spec.rb
...
it "sets the cookie" do
get :index
response.cookies['expiring_cookie'].should eq('All that we see or seem...')
# is but a dream within a dream.
# - Edgar Allan Poe
end
it "sets the cookie expiration" do
stub_cookie_jar = HashWithIndifferentAccess.new
controller.stub(:cookies) { stub_cookie_jar }
get :index
expiring_cookie = stub_cookie_jar['expiring_cookie']
expiring_cookie[:expires].to_i.should be_within(1).of(1.hour.from_now.to_i)
endThis technique is a great example of Test Spy described in Gerard Mezos book xUnit Test Patterns. Basically, you install a spy and check the results collected by the test spy in the verification phase. In this case the Hash is the Test Spy that collects data. See how the stub is used to install the spy in the SUT? It overcomes the problems and isolates the SUT from the Rails framework and allows the code to be tested easily.
In my TDD bootcamps, the topic on Stubs and Mocks generates lot of discussion. To clear confusion that surrounds the stubs and mocks, I would state : Read Martin Fowler's paper on Mocks Aren't Stubs, Stub can never fail your test, only mocks can fail your test. Using stubs in combination with a spy like this makes stubs seem like they can in fact fail your test. But only the data collected by the Test Spy decides whether the test passes or not. So the stub's main purpose is to just isolate the production code from Rails framework and allow access to the internal state of the SUT where there is no direct way to access it.
Saturday, March 10, 2012
TDD Bootcamp Videos
You can watch the TDD Bootcamp videos on YouTube. It is over 5.5 hours of recording.
Tuesday, February 07, 2012
Testing and Command Query Separation Principle
The term 'command query separation' was coined by Bertrand Meyer in his book "Object Oriented Software Construction".
The fundamental idea is that we should divide an object's methods into two categories:
Queries: Return a result and do not change the observable state of the system (are free of side effects).
Commands: Change the state of a system but do not return a value.
Because the term 'command' is widely used in other contexts it is referred as 'modifiers' and 'mutators'.
It's useful if you can clearly separate methods that change state from those that don't. This is because you can use queries in many situations with much more confidence, changing their order. You have to be careful with modifiers.
The return type is the give-away for the difference. It's a good convention because most of the time it works well. Consider iterating through a collection in Java: the next method both gives the next item in the collection and advances the iterator. It's preferable to separate advance and current methods.
There are exceptions. Popping a stack is a good example of a modifier that modifies state. Meyer correctly says that you can avoid having this method, but it is a useful idiom. Follow this principle when you can.
From jMock home page: Tests are kept flexible when we follow this rule of thumb: Stub queries and expect commands, where a query is a method with no side effects that does nothing but query the state of an object and a command is a method with side effects that may, or may not, return a result. Of course, this rule does not hold all the time, but it's a useful starting point.
The fundamental idea is that we should divide an object's methods into two categories:
Queries: Return a result and do not change the observable state of the system (are free of side effects).
Commands: Change the state of a system but do not return a value.
Because the term 'command' is widely used in other contexts it is referred as 'modifiers' and 'mutators'.
It's useful if you can clearly separate methods that change state from those that don't. This is because you can use queries in many situations with much more confidence, changing their order. You have to be careful with modifiers.
The return type is the give-away for the difference. It's a good convention because most of the time it works well. Consider iterating through a collection in Java: the next method both gives the next item in the collection and advances the iterator. It's preferable to separate advance and current methods.
There are exceptions. Popping a stack is a good example of a modifier that modifies state. Meyer correctly says that you can avoid having this method, but it is a useful idiom. Follow this principle when you can.
From jMock home page: Tests are kept flexible when we follow this rule of thumb: Stub queries and expect commands, where a query is a method with no side effects that does nothing but query the state of an object and a command is a method with side effects that may, or may not, return a result. Of course, this rule does not hold all the time, but it's a useful starting point.
Saturday, February 04, 2012
Stubs are not Mocks - Concise Version of Martin Fowler's Article
Stubs - a common helper to testing environments. There is a difference in how test results are verified: a distinction between state verification and behavior verification. Focusing on one element of the software at a time -hence the common term unit testing. The problem is that to make a single unit work, you often need other units.
- Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
- Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
- Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.
- Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
Only mocks insist upon behavior verification. The other doubles can, and usually do, use state verification.
The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior.
An acknowledged issue with state-based verification is that it can lead to creating query methods only to support verification. It's never comfortable to add methods to the API of an object purely for testing, using behavior verification avoids that problem.
Subscribe to:
Posts (Atom)