redding / assert Goto Github PK

Just like context level ones, except suite-level, so they run when before the entire suite starts and after the suite is finished. I'd call/alias as 'before_once', 'after_once', 'setup_once', 'teardown_once'. Something like that.

~/.assert/options.rb or something like that

not sure what to show just yet.

too subjective.

Only ran into a couple issues, very minor:

• With the brew formula, I'd recommend you add something about saving the file as rb.rb. I saved this as rbcmd.rb and brew gets upset about that. It's kinda obvious if you read the error message and the formula, but had to see it error first.
• Your example cmd aliases have a duplicate for the alias 'l'. I copied in the aliases and ran rb l and got the usage message for rb local. So list and local are aliased the same in your example. I switched list to use ls and all is good.

right now it has methods for getting the 'fail_results' and the 'error_results'. for consistancy, add methods for 'pass_results' and 'skip_results'.

• just the basics
  ** spit out runtime result notations
  ** barf out all error or failed result details
  ** show summary line

• look at 1.8.7 test-unit, 1.9 minitest
• do some meth missing action for any assertion helpers we are choosing to not implement
• have them raise a new type of result called 'ignored' or something
• this is so that it won't break backwards compatibility, but at the same time we don't have to implement every little helper the old libs do.
• if we ever decide to implement more macros, we just do it and take them out of the ignored ones.

• look for a ~/.assert file or something
• put JSON settings in there
• have assert parse those settings and apply at suite load time
• setting could include
  ** specify custom view classes to use
  ** color output or no?
  ** override colors for different results
  ** focus mode or no?
  ** run tests in parrallel or no? how many cores to use?

The methods should take a message like the fail method. It should add the message to the result similarly.

just for clarity and cleanup and documentation help.

• put all view related code in assert-views repo.

A feature of Shoulda I use all the time is mocking out my tests with should statements, but not providing the blocks until I am ready to implement the test. Right now I just get an error saying I need to pass a block. It would be nice if when I call should with no block it just shows as a skipped test.

it's optional - you can use it if you want or not.

let's discuss this. I think we should be consistant here and have args be passed to helpers in similar ways. For example, assert_equal is assert_equal <expectedval>, <testval>. However assert_respond_to is assert_respond_to <testobj>, <expected>. Let's chat on monday.

right now its not (in the context class). Need to right a test for this and get it passing.

Context should have a class method should that takes a string and a block. This should create a new test similarly to how a method named test_* works.

i think this is a better and more stable handler to build 3rd-party terminal views with.

The nice automatic rake test tasks generated have some strange behavior with Rake 0.9.2. This seems to be due to the fact that tests like rake test:context are defined twice. With rake 0.9.2 this runs both and runs them separately which is odd. This needs to be cleaned up.

do it more like bundler

• class meth version should take a block
• instance meth version should eval the block in the scope of the context and return the blocks return value
• look to test-beltv2.0 for reference

if user opts in to using the assert auto test tasks, go ahead and include Rake::DSL if defined for them so they don't get crappy rake warnings.

A context's and suite's setup and teardown methods should support being passed a string/symbol without a block. Rails test case extensions expect to be able to call setup and teardown in this manner so this should make it even more seamless.

alias of 'should'

right now the test suite is written using patterns only supported by test-unit (or assert itself). I'd like to port the test suite to super vanilla test-unit/minitest so that we can test assert independently of itself.

make more like test-belt, shoulda - open up for easy macro-ing

• alias with before/after
• should honor nested contexts
• blocks should run in the scope of the context
• look to test-belt v2.0 for reference

only show type and message

please.

This one is minor. The '.'s at the end of the test change order drastically every time I add a test. It is a little disorienting when I have a few 'S' tests and they shift all over the place each time I add a new assert statement to a test. It looks like Hash order behavior so it is likely not a problem in Ruby 1.9. If it is an easy fix I think deterministic ordering would be a nice polish.

TODOs

make them actually work by comparing type/message

Both Rails' ActionController and basic Rack::Test versions. Consider moving rails specific assert stuff into its own gem, 'assert-rails' or something. Want to keep the main 'assert' gem Rails' agnostic.

uhh, fix this.

we need docs baby. use docs to drive examples.

• assert_equal
• assert_raises
• etc
• decide and implement certain common and basic assertion macros/helpers

Optionally, capture std output and store with the result.

• capture any std output that is accumulated with the test as it runs.
• when displaying test results, show the std output accumulated with any result details.
• display nicely please.

Both Rails specific and Rack::Test generic. Again, consider putting rails specific junk in own gem, 'assert-rails' or whatever.

• add a 'desc' context class meth that takes a string
• the context desc string should be built honoring nested contexts
• should be prepended to the names of any tests for the context
• should be totally optional
• look to test-belt v2.0 for reference

does the same thing as 'should' but just skips

Wanted to write this down before I forget it. In test/helper.rb the top comment says "test_belt" instead of "assert".

pull from test-belt (shoulda) but I'd like to discuss a redesign to make it simpler.

please.

defaults to Terminal if now opt

• make false by default

going to use in the ignored assertion stuff we will do in Issue #5