I am starting with DDD and TDD in a Ruby application using Minitest.
I created a repository class (no database access, but it generates the entities for me). It is a singleton.
I would like to test the generation of the entities. The problem is that because it is a singleton, the order of executions of the tests affect the results.
Is there any way to force the disposal of the singleton element so it is "fresh"?
Here is my repository code:
require "singleton"
class ParticipantRepository
include Singleton
def initialize()
#name_count = 0
end
def generate_participant()
participant = Participant.new
participant.name = "Employee#{get_name_count()}"
return participant
end
private
def get_name_count()
old_name_count = #name_count
#name_count += 1
return old_name_count
end
end
And the tests:
require_relative 'test_helper'
class ParticipantRepositoryTest < MiniTest::Unit::TestCase
def setup()
#repository = ParticipantRepository.instance
end
def test_retrieve_participant
participant = #repository.generate_participant
refute_nil participant
refute_nil participant.name
refute_equal("", participant.name)
assert_equal(0, participant.subordinates_count)
end
def test_employee_name_increment
participant1 = #repository.generate_participant
participant2 = #repository.generate_participant
refute_equal(participant1.name, participant2.name)
index_participant1 = /Employee([0-9]+)/.match(participant1.name)[1]
index_participant2 = /Employee([0-9]+)/.match(participant2.name)[1]
assert_equal(0, index_participant1.to_i)
assert_equal(1, index_participant2.to_i)
end
end
The assertion assert_equal(0, index_participant1.to_i) succeeds when test_employee_name_increment is executed first and fails if it is executed last.
I would like to be able to test the repository (because it will evolve into something bigger). How can I do that?
Thanks!
Ordering your tests won't matter. To properly test a singleton class you need to treat it like an instance object. To do that, wrap your singleton in an anonymous Class during setup. Every time setup is called you'll get an untouched copy of the ParticipantRepository:
def setup
#repository = Class.new(ParticipantRepository).instance
end
Call i_suck_and_my_tests_are_order_dependent!() at the top of your
tests when you absolutely positively need to have ordered tests. In
doing so, you’re admitting that you suck and your tests are weak.
...I promise I didn't write this method or the docs.
For more info, see: http://www.ruby-doc.org/stdlib-2.0/libdoc/minitest/rdoc/MiniTest/Unit/TestCase.html#method-c-i_suck_and_my_tests_are_order_dependent-21
Related
Hello i am trying to test method that in one place calls activerecord attribute, but however in test i created fake class to test it out and do not have a table for that test class, so how i could give that class a fake table or smthng?
tried to define load schema, but that didn't work:
class TestClassStatus < FrozenRecord::Base
end
class TestClass < ApplicationRecord
def self.load_schema!
#columns_hash={"test_class_status_id" => {#name=>'test_class_status_id', #table_name=>'TestClassStatus', #sql_type_metadata=>{ #sql_type=>'character varying', #type=>:string, #limit=>nil, #precision=>nil, #scale=>nil }, #null=>false, #default=>'', #default_function=>nil, #collation=>nil, #comment=>nil, #max_identifier_length=>63}}
end
has_status
end
here i have TestClassStatus where statuses from yml file are loaded by frozen record, and TestClass is a class where i use the method i want to test has_status. And that method is trying to find test_class_status_id in TestClass. But unfortunately i dont have a table for that fake TestClass. So any advice how to make a fake table for that TestClass to run this spec? :)
Thank you in advance!
Here is a part where it breakes
name = status_name ? status_name.to_s : "#{self.to_s}Status"
klass = name.camelize.constantize
include Module.new {
class_eval %Q{
def #{association_name}
#{klass}.find(self[:#{name.underscore}])
end
}
}
It brakes in line where it tries to find that attribute. klass in my case will be TestClassStatus and name will be test_class_status so in that line it tries to recieve test_class_status attribute in TestClass, but unfortunately as you can see my TestClass does not have a table. So i need somehow to fake the table, because this method hits activerecord :)
There is a way to test it using real class, but I don't want to be attached to a real class in testing in case someday i would need to remove that class.
I have problem stubbing external api, following is the example
require 'rspec'
require 'google/apis/storage_v1'
module Google
class Storage
def upload file
puts '#' * 90
puts "File #{file} is uploaded to google cloud"
end
end
end
class UploadWorker
include Sidekiq::Worker
def perform
Google::Storage.new.upload 'test.txt'
end
end
RSpec.describe UploadWorker do
it 'uploads to google cloud' do
google_cloud_instance = double(Google::Storage, insert_object: nil)
expect(google_cloud_instance).to receive(:upload)
worker = UploadWorker.new
worker.perform
end
end
I'm trying to stub Google::Storage class. This class is instantiated inside the object being tested. How can I verify the message expectation on this instance?
When I run above example, I get following output, and it seems logical, my double is not used by tested object
(Double Google::Storage).upload(*(any args))
expected: 1 time with any arguments
received: 0 times with any arguments
I'm new to Rspec and having hard time with this, any help will be appreciated.
Thanks!
Reaching for DI is always a good idea (https://stackoverflow.com/a/51401376/299774) but there are sometimes reasons you can't so it, so here's another way to stub it without changing the "production" code.
1. expect_any_instance_of
it 'uploads to google cloud' do
expect_any_instance_of(Google::Storage).to receive(:insert_object)
worker = UploadWorker.new
worker.perform
end
In case you just want to test that the method calls the method on any such objects.
2. bit more elaborated setup
In case you want to control or set up more expectations, you can do this
it 'uploads to google cloud' do
the_double = instance_double(Google::Storage)
expect(Google::Storage).to receive(:new).and_return(the_double)
# + optional `.with` in case you wanna assert stuff passed to the constructor
expect(the_double).to receive(:insert_object)
worker = UploadWorker.new
worker.perform
end
Again - Dependency Injection is clearer, and you should aim for it. This is presented as another possibility.
I would consider reaching for dependency injection, such as:
class UploadWorker
def initialize(dependencies = {})
#storage = dependencies.fetch(:storage) { Google::Storage }
end
def perform
#storage.new.upload 'test.txt'
end
end
Then in the spec you can inject a double:
storage = double
expect(storage).to receive(...) # expection
worker = UploadWorker.new(storage: storage)
worker.perform
If using the initializer is not an option then you could use getter/setter method to inject the dependency:
def storage=(new_storage)
#storage = new_storage
end
def storage
#storage ||= Google::Storage
end
and in the specs:
storage = double
worker.storage = storage
I am learning Ruby with TDD using Mocha and MiniTest.
I have a class that has one public method and many private methods, so the only method my tests are going to tests are the public one.
This public method does some processing and creates an array which is sent to another object:
def generate_pairs()
# prepare things
pairs = calculate_pairs()
OutputGenerator.write_to_file(path, pairs)
end
Great. To test it, I would like to mock the OutputGenerator.write_to_file(path, pairs) method and verify the parameters. My first test I could sucessfully implement:
def test_find_pair_for_participant_empty_participant
available_participants = []
OutputGenerator.expects(:write_to_file).once.with('pairs.csv', [])
InputParser.stubs(:parse).once.returns(available_participants)
pair = #pairGenerator.generate_pairs
end
Now I would like to test with one pair of participants.
I am trying this
def test_find_pair_for_participant_only_one_pair
participant = Object.new
participant.stubs(:name).returns("Participant")
participant.stubs(:dept).returns("D1")
participant_one = Object.new
participant_one.stubs(:name).returns("P2")
participant_one.stubs(:dept).returns("D2")
available_participants = [participant_one]
OutputGenerator.expects(:write_to_file).once.with('pairs.csv', equals([Pair.new(participant, participant_one)])) # here it fails, of course
InputParser.stubs(:parse).once.returns(available_participants)
#obj.stubs(:get_random_participant).returns(participant)
pair = #obj.generate_pairs
end
The problem is that equals will only match the obj reference, not the content.
Is there any way I can verify the content of the array? Verifying the number of elements inside the array would also be extremely useful.
ps: I am sorry if the code doesn't follow ruby standards, I am doing this project to learn the language.
What you are testing here demonstrates a kind of hard coupling. That is your primary class is always dependent on OutputGenerator which makes testing your outputs tricky and can lead to a lot of pain if/when you have to refactor your designs.
A good pattern for this is dependency injection. With this you can just write a temporary ruby object you can use to evalute the output of your function however you want:
# in your main class...
class PairGenerator
def initialize(opts={})
#generator = opts[:generator] || OutputGenerator
end
def generate_pairs()
# prepare things
pairs = calculate_pairs()
#generator.write_to_file(path, pairs)
end
end
# in the test file...
# mock class to be used later, this can be at the bottom of the
# test file but here I'm putting it above so you are already
# aware of what it is doing
#
class MockGenerator
attr_reader :path, :pairs
def write_to_file(path, pairs)
#path = path
#pairs = pairs
end
end
def test_find_pair_for_participant_only_one_pair
participant = Object.new
participant.stubs(:name).returns("Participant")
participant.stubs(:dept).returns("D1")
participant_one = Object.new
participant_one.stubs(:name).returns("P2")
participant_one.stubs(:dept).returns("D2")
available_participants = [participant_one]
# set up a mock generator
mock_generator = MockGenerator.new
# feed the mock to a new PairGenerator object as a dependency
pair_generator = PairGenerator.new(generator: mock_generator)
# assuming this is needed from your example
pair_generator.stubs(:get_random_participant).returns(participant)
# execute the code
pair_generator.generator_pairs
# output state is now captured in the mock, you can evaluate for
# all the test cases you care about
assert_equal 2, mock_generator.pairs.length
assert mock_generator.pairs.include?(participant)
end
Hope this helps! Dependency Injection is not always appropriate but it is great for cases like this.
Some other posts about the use of dependency injection you might find helpful:
Dependency Injection in Ruby
A Ruby Refactor: Dependency Injection Options
Simple Dependency Injection in Ruby
I have a design problem.
I'm writing a REST client in ruby. For reasons beyond my control, it has to extend another gem that uses my networks zookeeper instance to do service lookup. My client takes a user provided tier, and based on that value, queries the zookeeper registry for the appropriate service url.
The problem is that I also need to be able to run my client against a locally running version of the service under test. When the service is running locally, zookeeper is obviously not involved, so I simply need to be able to make GET requests against the localhost resource url.
When a user instantiates my gem, they call something like:
client = MyRestClient.new(tier: :dev)
or in local mode
client = MyRestClient.new(tier: :local)
I would like to avoid conditionally hacking the constructor in MyRestClient (and all of the GET methods in MyRestClient) to alter requests based on :local vs. :requests_via_the_zk_gem.
I'm looking for an elegant and clean way to handle this situation in Ruby.
One thought was to create two client classes, one for :local and the other for :not_local. But then I don't know how to provide a single gem interface that will return the correct client object.
If MyClient has a constructor that looks something like this:
class MyClient
attr_reader :the_klass
def initialize(opts={})
if opts[:tier] == :local
#the_klass = LocalClass.new
else
#the_klass = ZkClass.new
end
#the_klass
end
end
then I end up with something like:
test = MyClient.new(tier: :local)
=> #<MyClient:0x007fe4d881ed58 #the_klass=#<LocalClass:0x007fe4d883afd0>>
test.class
=> MyClient
test.the_klass.class
=> LocalClass
those who then use my gem would have to make calls like:
#client = MyClient.new(tier: :local)
#client.the_klass.get
which doesn't seem right
I could use a module to return the appropriate class, but then I'm faced with the question of how to provide a single public interface for my gem. I can't instantiate a module with .new.
My sense is that this is a common OO problem and I just haven't run into it yet. It's also possible the answer is staring me in the face and I just haven't found it yet.
Most grateful for any help.
A common pattern is to pass the service into the client, something like:
class MyClient
attr_reader :service
def initialize(service)
#service = service
end
def some_method
service.some_method
end
end
And create it with:
client = MyRestClient.new(LocalClass.new)
# or
client = MyRestClient.new(ZkClass.new)
You could move these two into class methods:
class MyClient
self.local
new(LocalClass.new)
end
self.dev
new(ZkClass.new)
end
end
And instead call:
client = MyRestClient.local
# or
client = MyRestClient.dev
You can use method_missing to delegate from your client to the actual class.
def method_missing(m, *args, &block)
#the_class.send(m, *args, &block)
end
So whenever a method gets called on your class that doesn't exist (like get in your example) it wil be called on #the_class instead.
It's good style to also define the corresponding respond_to_missing? btw:
def respond_to_missing?(m, include_private = false)
#the_class.respond_to?(m)
end
The use case you are describing looks like a classic factory method use case.
The common solution for this is the create a method (not new) which returns the relevant class instance:
class MyClient
def self.create_client(opts={})
if opts[:tier] == :local
LocalClass.new
else
ZkClass.new
end
end
end
And now your usage is:
test = MyClient.create(tier: :local)
=> #<LocalClass:0x007fe4d881ed58>
test.class
=> LocalClass
I know. This is discouraged. For reasons I won't get into, I need to run my tests in the order they are written. According to the documentation, if my test class (we'll call it TestClass) extends Minitest::Unit::TestCase, then I should be able to call the public method i_suck_and_my_tests_are_order_dependent! (Gee - do you think the guy who created Minitest had an opinion on that one?). Additionally, there is also the option of calling a method called test_order and specifying :alpha to override the default behavior of :random. Neither of these are working for me.
Here's an example:
class TestClass < Minitest::Unit::TestCase
#override random test run ordering
i_suck_and_my_tests_are_order_dependent!
def setup
...setup code
end
def teardown
...teardown code
end
def test_1
test_1 code....
assert(stuff to assert here, etc...)
puts 'test_1'
end
def test_2
test_2_code
assert(stuff to assert here, etc...)
puts 'test_2'
end
end
When I run this, I get:
undefined method `i_suck_and_my_tests_are_order_dependent!' for TestClass:Class (NoMethodError)
If I replace the i_suck method call with a method at the top a la:
def test_order
:alpha
end
My test runs, but I can tell from the puts for each method that things are still running in random order each time I run the tests.
Does anyone know what I'm doing wrong?
Thanks.
If you just add test_order: alpha to your test class, the tests will run in order:
class TestHomePage
def self.test_order
:alpha
end
def test_a
puts "a"
end
def test_b
puts "b"
end
end
Note that, as of minitest 5.10.1, the i_suck_and_my_tests_are_order_dependent! method/directive is completely nonfunctional in test suites using MiniTest::Spec syntax. The Minitest.test_order method is apparently not being called at all.
EDIT: This has been a known issue since Minitest 5.3.4: see seattlerb/minitest#514 for the blow-by-blow wailing and preening.
You and I aren't the ones who "suck". What's needed is a BDD specification tool for Ruby without the bloat of RSpec and without the frat-boy attitude and contempt for wider community practices of MiniTest. Does anyone have any pointers?
i_suck_and_my_tests_are_order_dependent! may be a later addition to minitest & not available as a Ruby core method. In that case, you'd want to force use of your gem version:
require 'rubygems'
gem 'minitest'
I think that the method *test_order* should be a class method and not a instance method like so:
# tests are order dependent
def self.test_order
:alpha
end
The best way to interfere in this chain may be to override a class method runnable_methods:
def self.runnable_methods
['run_first'] | super | ['run_last']
end
#Minitest version:
def self.runnable_methods
methods = methods_matching(/^test_/)
case self.test_order
when :random, :parallel then
max = methods.size
methods.sort.sort_by { rand max }
when :alpha, :sorted then
methods.sort
else
raise "Unknown test_order: #{self.test_order.inspect}"
end
end
You can reorder test any suitable way around. If you define your special ordered tests with
test 'some special ordered test' do
end
, don't forget to remove them from the results of super call.
In my example I need to be sure only in one particular test to run last, so I keep random order on whole suite and place 'run_last' at the end of it.