On 22 Nov 2006, at 16:12, [EMAIL PROTECTED] wrote:
You could write your Assert to do nothing in a release build, but it's
not clear to me why you would want to. At the very least, it should
log the error to a file that you can then ask your users for when
things seem to go wrong. (And things WILL go wrong.)
It's also not clear to me how RS could write this Assert method for
you. I'm quite sure they don't know what I want it to do, since in
different projects I may have it do different things. One client
wants
it to display a message box; another wants it to use
System.DebugLog; a
third wants the error written to their own log file. If they were to
implement it, what makes you think they would choose whatever
functionality you happen to prefer?
I missed out on the original post, but could the poster maybe refer
to Asserts in a testing suite. I'm just pasting some ruby on rails
code here, because that's what I'm most familiar with:
def test_invalid_with_empty_attributes
product = Product.new
assert !product.valid?
assert product.errors.invalid?(:title)
assert product.errors.invalid?(:description)
assert product.errors.invalid?(:price)
assert product.errors.invalid?(:image_url)
end
def test_positive_price
product = Product.new(:title => "My Book Title",
:description => "yyy",
:image_url => "zzz.jpg")
product.price = -1
assert !product.valid?
assert_equal "should be at least 0.01", product.errors.on(:price)
product.price = 0
assert !product.valid?
assert_equal "should be at least 0.01", product.errors.on(:price)
product.price = 1
assert product.valid?
end
def test_image_url
ok = %w{ fred.gif fred.jpg fred.png FRED.JPG FRED.Jpg http://
a.b.c/x/y/z/fred.gif }
bad = %w{ fred.doc fred.gif/more fred.gif.more }
ok.each do |name|
product = Product.new(:title => "My Book Title",
:description => "yyy",
:price => 1,
:image_url => name)
assert product.valid?, product.errors.full_messages
end
bad.each do |name|
product = Product.new(:title => "My Book Title", :description
=> "yyy", :price => 1, :image_url => name)
assert !product.valid?, "saving #{name}"
end
end
Now, these are unit tests, and I believe Joe has already written an
article on that subject. However, comparing to other unit test
structures, it was a very simple (and incomplete) way of writing
automated tests. Integration in REALbasic would be great, so that
every time I build my application or start a debug session, those
tests are run and a simple report is presented:
- xxx tests in suite
- xxx tests passed
- xxx test failed:
• test_1
• test_2
• test_3
However, unit testing is just the first way of providing automated
testing. RoR for example allows, besides unit testing, functional
testing. Without going to much into detail, Rails (an MVC framework)
allows you to not only test your models (classes), but also your
controllers and views (functional testing).
Translating the to REALbasic, testing your GUI, by writing something
like:
StaticText1.text="Something"
PushButton1.click
assert_equal(StaticText1.text="Not the same")
Especially on bigger projects, where you might need to refactor or
rewrite a complete part of your application, these automated tests
will prevent your application from breaking on the obvious stuff. I
remember my first few Rails apps, for which I didn't write automated
tests. In the weeks after changing something mostly resulted in other
stuff breaking. Then I started writing automated tests (and better
code too, I have to admit :-)) and it's been a real joy: a lot less
bugs and so easy to maintain.
Best regards
Peter De Berdt
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
