<aturley>
basically, i define the tests as object literals inside an array and then loop through the array, picking them off and calling `test` with them.
<aturley>
this is most certainly ugly.
<aturley>
BUT ... it means that now all my tests always run.
<aturley>
i thought i'd share this so in case other folks had the same problem i have.
<aturley>
i don't think i'd recommend this as the "right" way to do things, but it has helped me for these little toy programs.
<vaninwagen>
some automatic test discovery would be the real deal
<aturley>
vaninwagen agreed, but we aren't really close to having anything like that yet.
<vaninwagen>
some cli script, that scans some packages and runs everything that extends TestCase
<srenatus>
thanks for sharing!
<srenatus>
I wonder if we'd want to imitate what Go does -- if your object has the proper name prefix, it's considered a test and included... yes what @vaninwagen said.
<vaninwagen>
errr, UnitTest
<srenatus>
"that extends UnitTest" is also better than the naming convention! +1
<aturley>
cli tool would be nice, but at some point it could get a little complicated. you could start simple and look for class definitions that end in ` is UnitTest`, which would probably get you 90% of the way. but the other 10% would probably require writing a parser.
<aturley>
you could maybe use the AST instead of the raw Pony code to look for your test classes.
<aturley>
then you get into the fun of figuring out how to define groups, and exclusions, and ...
<vaninwagen>
The tool would need to build a binary, that detects UnitTests and builds the TestList stuff
<vaninwagen>
Yeah, and those fun things
<aturley>
lots of yaks to shave.
<vaninwagen>
Oh yeah, with a dull spoon
<aturley>
that's why i like the technique i'm using for now. it brings the smallest number of yaks into the room.
<vaninwagen>
I also like it
<vaninwagen>
Less yaks equals more fun
<srenatus>
just how dull is it? I mean, I'm just getting my feet wet, so I can't answer this myself: would there be a way in which ponytest could detect the UnitTests "in the binary"?
<vaninwagen>
If the UnitTests arent referenced somehow, they would be excluded from the binary :(
<aturley>
yup.
<srenatus>
ah I see. and if we have to reference them, we might as well just list them as is done now; or using the more convenient hack presented by @aturley. got it. thank you.
<aturley>
another option would be to add support for something like this to the compiler itself, and justify it by saying that ponytest is part of pony in a fundamental way.
<aturley>
i'm not super happy about the idea of giving ponytest special status like that.
<vaninwagen>
Or we "just" quickly invent macros to handle the boilerplate
<vaninwagen>
*what a day for a daydream*
* aturley
pushes the eject button, bails out
* aturley
re-enters the plane through a side door
acarrico has quit [Ping timeout: 250 seconds]
* vaninwagen
pulls out 2 uzis i taped underneath the seat before the flight (dressed up as airport staff)
<aturley>
with my hack, i was wondering if it was useful enough to consider adding a method to the PonyTest class that takes a list of tests and applies each of them.
<vaninwagen>
I would love that
<aturley>
basically something that automates what i'm doing with the `while` loop at the end of my `tests` method.
<aturley>
i think you'd have to pass it an iso array, and the array would be emptied out.
<aturley>
can somebody see a better way?
<vaninwagen>
Or a val array with iso UnitTests?
<vaninwagen>
Ah no, you'd only get vals from that
<aturley>
yup
<vaninwagen>
Would you?
<aturley>
yes
<SeanTAllen>
What do you do aturley if you want to turn a test off for some period of time?
<aturley>
SeanTAllen good question! since this is a toy project i really haven't run into that. if i had to do it, i'd probably comment the test out.
<aturley>
which isn't great.
<vaninwagen>
But you could still exclude them from the ponytest cli, no?
<aturley>
vaninwagen yes, you could do that as well.
<SeanTAllen>
i think that Pony could really stand to have macros but that is a lot of work and someone would need to put a lot of thought into the RFC
<aturley>
SeanTAllen agreed
<SeanTAllen>
the way that most languages handle this is through reflection at runtime and that is fraught with far more problems than macros or compile time expressions.
acarrico has joined #ponylang
<SeanTAllen>
i'd rather see macros/compile time expressions as the approach than reflection
<aturley>
SeanTAllen agreed with that as well.
<SeanTAllen>
capabilities secure reflection is not exactly a well established field with lots of in industry usage
<aturley>
i've accepted that macros are long way off, so i'm looking for solutions to the UX problem that seems to exist with ponytest.
<SeanTAllen>
yup
endformationage has joined #ponylang
<Candle>
aturley: That does "fix" one of my annoyances - with ponytest you need to have the name of the test twice; once in the class name and once in the name() function.
<SeanTAllen>
interesting... i dont have the same name in the class and the name() function Candle
<SeanTAllen>
with your stuff, the string returned from name() is the classname? that's how you set it up?
<Candle>
Well, it's not exactly the same name, but there are often similarities.
<_andre>
if you change it to 'Random iso' then i get "this capture violates capabilities, because the match would need to differentiate by capability at runtime instead of matching on type alone" on the 'let r = ...'
<_andre>
stupid question: why does the string() method from Stringable return a String iso^ (as opposed to, say, a val)?
<SeanTAllen>
not a stupid question!
<_andre>
hehe
<SeanTAllen>
so, why do you think it should return a val?
<SeanTAllen>
or rather
<SeanTAllen>
why do you think that val might be a reasonable thing for it to do?
<_andre>
i found it surprising because Strings are val by default, so i expected a val return type, and also because it seems to require an extra clone() for every implementation, which could be done by callers who need it
<_andre>
i.e. `return "foo".clone()`
<SeanTAllen>
i guess it depends on what one expects to happen with the result of that call
<SeanTAllen>
should it be mutable?
<SeanTAllen>
if its iso^ then you can do whatever you want with it
<SeanTAllen>
there are no other references so you can assign to a val, an iso, a ref or anything else
<SeanTAllen>
iso ^ is the most permissive option
<SeanTAllen>
maybe that isnt the best option
<SeanTAllen>
it would be interesting to look at the use of "string" in pony codebases and see how it is most commonly used
<_andre>
yeah, i tend to always use immutable strings, though i can see how that is the most flexible return type
<aturley>
some of the things around strings seem very opinionated and a little inconsistent.
<aturley>
strings have a default refcap of `val`, which makes me think that the idea is that pony guides you toward using immutable strings.
<aturley>
the default constructor returns a `ref`, which kind of makes sense i guess.
<aturley>
but then you have a thing that trips up newbies all the time, where `let a: String = String` doesn't compile.
<aturley>
then you have the about `string()` being defined in `Stringable` as returning an `iso ^`.
<aturley>
which gives the most flexibility.
<aturley>
each of these choices makes sense in some way, but i'm not sure they all make the most sense together, as a consistent whole.
<aturley>
well, specifically they don't seem to cohere in my mind, but maybe that's just me.
<_andre>
i also found it a bit surprising in the String class that slice() copies data and trim() doesn't. the opposite naming would seem more intuitive to me.
<aturley>
it's all second nature to me at this point so i don't think about it much anymore.
<SeanTAllen>
I'd remove val as the default from String
<aturley>
let a million backward compatibility issues bloom!
<aturley>
:)
<SeanTAllen>
its really only helpful with constants or the results of building up a string in a recover block
<SeanTAllen>
i would be in favor of doing away with class X foo
<SeanTAllen>
and not allow you to set X
<_andre>
for mutable strings wouldn't an Array[U8] be preferred?
<SeanTAllen>
depends
<SeanTAllen>
do you only care about the string as a series of bytes?
<SeanTAllen>
if yes, yes
<SeanTAllen>
but i think many people care more about the runes
<SeanTAllen>
in which case array[u8] isnt very helpful
travis-ci has joined #ponylang
<travis-ci>
ponylang/ponyc#5520 (master - 2f2a84e : Stephan Renatus): The build was broken.
<_andre>
any comments and suggestions about the code are also appreciated
<_andre>
i went with an uuid.Parse primitive so that i can return a union type with specific parse errors instead of a partial constructor. not sure how idiomatic that is.
<vaninwagen>
Me neither, but i like this package
srenatus has quit [Quit: Connection closed for inactivity]