I want to do an IMAP search that searches for multiple SUBJECT matches.
If I do the search below - I get the results I need:
SUBJECT "Transfer code" SINCE ...
Same for this one:
SUBJECT "Transfercode" SINCE ...
However if I try to combine them, I get no results:
SUBJECT "Transfer code" OR SUBJECT "Transfer code" SINCE ...
I have tried every possible variant, but none of them work:
SUBJECT "Transfer code" OR SUBJECT "Transfercode" SINCE ...
OR SUBJECT "Transfer code" OR SUBJECT "Transfercode" SINCE ...
(SUBJECT "Transfer code" OR SUBJECT "Transfercode") ...
SUBJECT Transfer code OR SUBJECT Transfercode SINCE ...
Anyone knows how to accomplish this?
I'm using PHP Imap_search, and apparently the "OR" operator is not supported.
You'll need to search multiple times, and merge the results - as discussed in this question: https://stackoverflow.com/a/5264230/776264
Adding to Max's comment (since I lack the points), OR is a prefix operator and can only take two operands (not three). So the code should be:
SINCE "08-Mar-2011" OR SUBJECT "Transfer code" SUBJECT "Transfercode"'
If you have more than two, you need to add an OR:
e.g., 3 operands
SINCE "08-Mar-2011" OR OR SUBJECT "Transfer code" SUBJECT "Transfercode" SUBJECT "Xfer code"'
e.g., 4 operands
SINCE "08-Mar-2011" OR OR OR SUBJECT "Transfer code" SUBJECT "Transfercode" SUBJECT "Xfer code" SUBJECT "Xfercode"'
Related
I have a en.yml which contains the following
en:
article:
title:
format: "Requires at least one alphanumeric character"
title_format: "Title Requires at least one alphanumeric character"
The article.title.format is used in my article model and article.title_format is used in article_test test. Is there any way to make this DRY?
YAML is limited for things like this, but you do have anchors, aliases and merge_keys. This SO answer is VERY exhaustive on this issue.
So, you can repeat the exact same message, but not modify that message without some other library or code injection:
&standard_answer: "Requires at least one alphanumeric character"
en:
article:
title:
format: *standard_answer
title_format: *standard_answer
in Ruby, is equivalent to:
en:
article:
title:
format: "Requires at least one alphanumeric character"
title_format: "Requires at least one alphanumeric character"
To answer the question you aren't asking...
If you are trying to test model validations, I think you're doing too much anyway:
These will break if Rails decides to tweak the language used
Your tests now rely on your i18n file just to find a hard-coded string
It's less readable because the test constraints are now in 2 separate files (but it is more compact, so you could argue that)
What you want to know is: "Can I save this record without any alphanumeric characters in the title?"
I would only test whether the validation succeeds or fails.
If you're using RSpec, I like this pattern.
Or, another option, RSpec Expectations ships with Predicate matchers:
# prove the record is valid
expect(record).to be_valid
# make the record invalid in only 1 way
record.title = 'does not have a number'
expect(record).to be_invalid # also works: expect(record).not_to be_valid
Note that I'm making sure the record is valid first, then changing one thing, then checking for validity again. This helps ensure you are testing the right validation.
We're trying to express our requirements following the specification by example approach in the gherkin language. One part of the functionality is a check that under some conditions fails and should otherwise be positive. So we have many scenarios like this:
Given a <condition> //condition changes between scenario
When the check is performed
Then the result is negative
So after describing all the conditions under which check can fail, we would need one positive scenario like:
Given ... // this is what we're missing.
When the check is performed
Then the result is positive
We can't come up with a good way to formulate this one. Please note, this is part of a generic piece of functionality that can be extended by different products, so we can't just write: 'none of the above conditions apply'
Can any of you come up with a formulation that would mean something like Given there are no conflicting conditions, but is more testable?
Perhaps you could just do
When the check is performed
Then it works
It would be much better though if the scenarios talked about what is. Say we are signing in. I'd start with
When I sign in
Then I should be signed in
and then extend that for the sad paths
Given my email is invalid
When I sign in
Then I should not be signed in
All of the above would probably need some background e.g.
Given I am registered.
You don't have to have a given for every scenario
Here is an example imlementation for the Given
module RegistrationStepHelper do
def create_registered_user
# return a user who is registered and can sign in
...
def sign_in_as(user)
end
World RegistrationStepHelper
"Given I am registered" do
#i=create_registered_user
end
When "I sign in" do
sign_in_as: #i
end
...
for a slightly expanded example see here
I am using Ruby on Rails 3.2.2 and rspec-rails-2.8.1. I would like to output more information about tests that are going to be run, for example, this way:
# file_name.html.erb
...
# General idea
expected_value = ...
it "... #{expected_value}" do
...
end
# Usage that I am trying to implement
expected_page_title =
I18n.translate(
'page_title_html'
:user => #user.firstname
)
it "displays the #{expected_page_title} page title" do
view.content_for(:page_title).should have_content(expected_page_title)
end
Note: "Outputs" are intended to be those that are output when you run the rspec . --format documentation command line in the Terminal window.
Is it a right way to test?
Related questions:
How to use an instance variable throughout an Example Group, even if it is outside a Example?
Your question is going to solicit some opinions, but I'll try and justify mine with some examples.
Short answer: No, this isn't how you should be writing RSpec (or any test) descriptions. It's unconventional and doesn't add much value for the extra code.
Long answer: RSpec is a BDD (behavior driven development) tool that was designed to help describe the behavior and intent of your code at the same time as writing automated tests. When you think about the behavior of your code, does adding the expected result to the test description really add much value? If so, maybe you should rethink what you are testing.
For example, say you have a User class and you want to test a method that concatenates a user's first and last name:
describe User do
expected_full_name = 'Software Guy'
subject { User.new(first: 'Software', last: 'Guy') }
it 'should have the full name #{expected_full_name}' do
subject.full_name.should == 'Software Guy'
end
end
VS
describe User do
subject { User.new(first: 'Software', last: 'Guy') }
it 'should have a full name based on the first and last names' do
subject.full_name.should == 'Software Guy'
end
end
In the first test, what does having the expected result in the description really buy you? Does it tell you anything about the expected behavior of a user? Not really.
Take your example. If I was coming along to your project and saw a test description like that, I would be confused because it doesn't really tell me what is being tested. I would still need to look at the code to understand what is going on. Compare these two examples:
it "displays the #{expected_page_title} page title" do
view.content_for(:page_title).should have_content(expected_page_title)
end
Which would give you something in the console like:
"displays the My Awesome Title page title"
Compare that to:
it "should translate the page title" do
view.content_for(:page_title).should have_content(expected_page_title)
end
Which would be exactly the same in the console as it is in the test:
"should translate the page title"
Your obviously free to choose whichever one you want, but I am speaking from a few years of testing experience and highly recommend you don't do this.
How I can parameterize to pass information between shared_example/include_examples?
In my specific case, I want to feed several constants to shared_example.
I found answer by myself... (I was hunting for answer for this two hours.. found this just after posting this)
At David Chelimsky's site, in article "Specifying mixins with shared example groups in RSpec-2," I found that shared_example can accept block parameters, and include_example can give parameters..
shared_example "example_1" do |param|
it "does something" do
xx.should == param
end
end
and later...
include_examples "example_1", :value_1
This work well with my case.
Note that, this parametalization is documented as cucumber feature, so I could find RSPec::Core document at Relish, but not in the class documentation.
I need to change the subject of the emails on a low level.
What rails does is encoding the subject as quoted in whatever encoding is set.
What I need is to make it quoted but split into chunks of 64 byte, as hotmail doesn't really goes with the standards :/
How do I tell rails to take the subject as is?
I had a look at this as a follow up to my answer to the previous question. The problem lies with TMail. It automatically removes and carriage returns from the subject. I created the following monkey patch as it seems to be the only solution to stop TMail's behaviour.
module TMail
class SubjectHeaderField < UnstructuredHeader
def parse
#Do nothing
end
end
class HeaderField
FNAME_TO_CLASS = FNAME_TO_CLASS.merge('subject' => SubjectHeaderField)
end
end
If you include it in the mailer in Rails 2.3.x it should work. Alternatively you might want to look at http://github.com/mikel/mail/ which is the default mailer in Rails 3?
Then you can set the header before encoding as the previous answer showed.
"This is a very very long subject line of an email that hotmail has problems processing".scan(/.{1,16}/)
#=> ["This is a very v", "ery long subject", " line of an emai", "l that hotmail h", "as problems proc", "essing"]
I have done it at 16 chars, here's a link to the doc http://www.ruby-doc.org/core/classes/String.html#M000812
HTH