Index

Show enters and exits. Hide enters and exits.

01:13:29boyscoutUpdated MSpec source to 60fa49cd. - 258aefb - Brian Ford
01:13:29boyscoutUpdated CI specs to RubySpec 2a1a307e. - 1ab8ad9 - Brian Ford
01:18:54boyscoutCI: rubinius: 1ab8ad9 successful: 3241 files, 12123 examples, 36446 expectations, 0 failures, 0 errors
03:30:15matthewdbrixen: On the offchance you're still around... are there tests for Rubinius::Config somewhere? If not, should there be?
03:43:58ruematthewd: Check under rbconfig?
03:44:10rueOr did you mean some rbx-specific parts?
03:46:21matthewdrue: Yeah, the latter
06:10:28brixenmatthewd: there are no tests for Rubinius::Config
06:10:33brixenmatthewd: it's generated
06:10:38brixenbased on platform
06:10:44brixennot sure what the point of tests would be
06:15:33matthewdbrixen: I mean the prims that implement it, not the values therein
06:22:51matthewdbrixen: Trying to work out where to put specs for http://gist.github.com/331803
06:25:47brixenfor the parts in the vm, use vm tests like you have there
06:26:05brixenI don't see any ruby code in that gist
06:26:18brixenwas there ruby code that had a bug?
06:26:42matthewdThe first hunk is a change to a primitive... I couldn't see any VM tests covering prims, so assumed they were covered from specs
06:27:16brixenspecs for primitives are based on the method wrapping the primitive
06:27:33brixenwhat method wraps that primitive?
06:27:38matthewdYeah, that's what I figured. Which in this case, is Rubinius::Config.get
06:28:02brixenok
06:28:50brixenshould be spec/core/rubinius/config/get_spec.rb then I suppose
06:29:15matthewdI guess the trick will be the values, though
06:29:18brixenactually spec/core/config/get_spec.rb
06:29:48brixensince various things are under the Rubinius namespace, but doesn't really make sense to push them down a directory
06:29:54matthewdAs you said, the values are platform specific... so it's hard to say what the spec can actually depend on
06:30:06brixenspec/core spec/library, etc are all Rubinius specific
06:30:10matthewdShort of having the config-generating stuff spit out some guaranteed values in a special test. namespace
06:30:27brixenthere's no point making specs for the generated values
06:30:50brixenthe expected values would be generated too
06:31:02brixenwe don't control what the platform gives for a specific value
06:31:26matthewdYeah, but to have a spec that says "parses a value of 123123123123123 as a bignum", we need some way of getting that number into the VM's config
06:32:26brixenhuh?
06:33:22brixenagain, I think this test belongs in the vm tests
06:34:04matthewdOkay, I think I'm confused
06:35:58brixenI am too
06:36:08matthewdThere's no precedent of a call to vm_* in vm/test/... so it feels like this should be a spec (of the R::C.get method)
06:36:19brixenok
06:36:25brixenwhy can't it be?
06:36:29matthewdBut, the underlying data structure this primitive is reading is read-only
06:36:49brixenR::C.get("some number").should == some_bignum ?
06:36:57matthewdSo, the spec can't put a dummy value in there (to parse, and then assert about)
06:37:07brixenthen it needs to be a vm test
06:37:17brixenif you cannot provide it a value, how can you test it
06:37:21matthewdR::C.get("some.key.that.is.definitely.a.bignum").should be_kind_of(Bignum)
06:37:22brixen*what* are you testing even?
06:37:39brixen"how can the children learn if they cannot fit in the school???"
06:40:44matthewdI think I'm talking about two possibilities: one is that platform.conf is guaranteed to contain a line of "rbx.test.bignum = 999999999999", and the spec depends on that... the other, is yes, define it as a VM test
06:40:46brixenthis seems easy to test with a vm test
06:41:04matthewdOkay, I'll do that.
06:41:25brixenI don't think it makes sense to have to make platform.conf contain a value
06:41:43brixenyou can twiddle that data structure easily from a vm test
06:42:19matthewdErm... assuming prims can be called from the middle of nowhere (don't expect anything special of their state)... I haven't looked that deep yet.
06:44:40brixensure, this method is static
06:44:49brixenjust a plain old static C++ method
06:45:58matthewdvm_get_config_item(STATE, String* var)... I was just wary of the STATE param
06:51:31matthewdbrixen: Thanks. An offering to make up for annoying questions: http://gist.github.com/331810 :)
07:06:13brixenmatthewd: cool
07:06:39brixenmatthewd: lines 103-106 of that gist need work
07:06:45brixengenerally, should_not is not allowed
07:07:09brixenif it calls #to_i on its argument, there should be a should_receive(:to_i) in that example
07:08:04brixenlines 155-157 should be in specs like: it "raises a TypeError when passed nil"
07:08:07brixen...