<solnic>
snusnu: can you guys be less cryptic in your comments? :P
<snusnu>
lol
<solnic>
because seriously you could’ve written that in Japanese and my understanding would be the same
<snusnu>
solnic: well, mbj probably is the guy to do deeper explanations, but yeah, ducktrap's basically built to convert object graphs from a different (e.g. hash) representation, to some richer (domain) model, and back
<solnic>
yes I know
<solnic>
but he wrote “looks like A ducktrap”
<solnic>
whereas he actually meant the ducktrap, his project
<snusnu>
heh, i'd call that imprecise formulating of thoughts
<snusnu>
yeah
<solnic>
I see
<solnic>
makes more sense now
<snusnu>
the thing with ducktrap is this, it's *incredibly* powerful, can be used for lots of different stuff .. it's a data transformation algebra
<snusnu>
it can act as a sanitizer (for web "security"), it can be used as a mapper
<snusnu>
...
<snusnu>
it can be used as a (de)serializer
<snusnu>
really, it has lots of potential applications, it's good stuff
<solnic>
well, I never said it isn't
<snusnu>
of course not
<snusnu>
i too find it hard to imagine where it could/should be used
<solnic>
I’m also still not entirely sure if it could be used as a mapper in ROM
<snusnu>
it sorta fits in a lot of places, but i dunno how sensible it is to use it just about everywhere
<snusnu>
it probably could be used for that (mapper in ROM) .. but imo a "trimmed down" version of it
<solnic>
virtus is a very small (esp now) library that builds objects from hash of attributes. end of story
<snusnu>
it does a lot of error tracking which simply is overkill for typical rom usage
<solnic>
not a serializer, not a de-serializer
<snusnu>
see that's the thing, ducktrap is no (de)serializer per se … it just can be used as such
<snusnu>
really, data transformation algebra fits best
<solnic>
I see
<snusnu>
you can declare transformation ops, that can be inverted too
mbj has joined #rom-rb
<solnic>
btw do you know that I removed 4.5k LOC from virtus over the last couple of days? :P
<solnic>
if you don’t have those 4 minutes, I can just paste the most important quote ;)
<mbj>
already read it
<solnic>
so you disagree?
<mbj>
nope
<mbj>
but I create other consequences
<solnic>
wdym?
<mbj>
You take the consequence that a public interface is allowed to be mutation covered by use of other public interfaces?
<solnic>
something that I found…controversial was snusnu saying it’s OK to have some duplication in tests
<mbj>
solnic: Duplication in tests is a weakness of the test tool.
<mbj>
So for our current situartion I accept I have duplication in my tests to explicitly cover my public interfaces.
<solnic>
yes I’m leaning towards a strong opinion that you should be unit-testing objects, treating them as a unit, not their individual methods
<mbj>
But only till I wrote a new test tool that allows me to share invariants between tests of public interfaces.
<solnic>
i’m still on the fence, that’s why I said I’m leaning towards that
<mbj>
solnic: We are in sync with our reasonings.
<mbj>
solnic: But you take the consequence to avoid duplicatio with rspec.
<mbj>
solnic: I take the consequence to accept it till I created a new tool :D
<solnic>
I’m thinking hard about pros and cons and I’m starting to realize the benefits coming from that hard-core approach are far too small to justify the effort
<snusnu>
solnic: to clarify my position, sometimes i prefer duplication over obsessive drying of tests, making them harder to follow … i am, however, still on the side that says that for *library* code as fundamental as rom (components), we should aim for full mutation coverage of the *public api* .. and nothing more
<solnic>
yes I’m always talking about libs
<snusnu>
see, fowler's mostly talking about apps
<solnic>
my point is…the strongest argument I’ve heard from you so far is that you might have accidental coverage
<mbj>
solnic: I'm 100% confident it is possible to create a tool that allows you to declare invariants over a whole class/unit test while still testing public methods explicitly to allow a rspec-expansion level of 0
<solnic>
so I started thinking…what are the odds...
<solnic>
…of having that accidental cov
<solnic>
and I’m thinking…chances are very small
<snusnu>
mutant will never be as clever as we are … it has much, much more patience tho
<snusnu>
:p
<mbj>
snusnu: I'm not clever :D Mutant makeing me more dump.
<snusnu>
dumb btw, mbj
<snusnu>
:)
<solnic>
dude that typo you just did is pretty hilarious
<solnic>
:D
<snusnu>
:)
<solnic>
having said that…baby bath time so bbl :)
<snusnu>
hehe
<mbj>
lulz
<mbj>
p and b sound the same for my ear
<mbj>
so I do that type of typos/misspelling often.
* snusnu
nods
<snusnu>
;)
<snusnu>
oh and i specifically meant dump vs. dump btw .. i've seen you doing that quite a few times already, hence i remembered that you once said i should correct you if i notice ;)
<snusnu>
lol
<snusnu>
dump vs. dump obviously
<snusnu>
MWHHA
<snusnu>
damnit
<snusnu>
i give up
<solnic>
yea
<mbj>
Interesting martin folwer is NOT comparing the types of coverage.
<mbj>
He does not talk about line/branch/statement/mutation coverage.
<mbj>
Which is absolutely needed to classify a statement like: If a part of your test suite is weak in a way that coverage can detect, it's likely also weak in a way coverage can't detect.
robertjpayne has quit [Remote host closed the connection]
<snusnu>
imo the critical thing is that (i assume) that he's mostly talking about apps
<snusnu>
you obviously want to apply different "metrics" for those
<mbj>
snusnu: I'm doing the same with libs and apps.
<solnic>
yes +1 snusnu
<mbj>
snusnu: Bugs in libs affect n apps
<snusnu>
and that might be overkill mbj
<solnic>
app context is a totally different thing
<mbj>
snusnu: Bugs in apps affect n € I get for apps
<mbj>
snusnu: And € effect my ability to do libs.
<solnic>
mbj: it requires a huge experience and a lot of common sense to apply our practices properly in an app development context
<snusnu>
lol, one could argue that a little maintenance doesn't hurt €, depending on contracts
<snusnu>
:D
<mbj>
solnic: I do not tell $random developer to archieve 100% mutcov
<mbj>
solnic: I do not force teammembers to do it.
<solnic>
it’s not 0 or 1 unfortunately
<solnic>
so it’s up to project leaders / senior devs or whatever you want to call them to make good decisions re test coverage
<mbj>
solnic: I start with the most critical part
<mbj>
solnic: Than expand slowly to "parts that are not under hard flux" anymore.
<mbj>
solnic: I'm talking about the 100% coverage target.
<mbj>
solnic: My apps have around 95% - 98% mutcov.
<solnic>
it really boils down to having an app that works™ because once the cost of fixing bugs is lower than building a test suite that would’ve prevented those bugs then…well, the decision is pretty easy
<solnic>
depends depends depends :)
<mbj>
haha
<mbj>
I'm gona grap some food
<solnic>
grab :)
<solnic>
joining the auto-correct team, sorry ;) you asked for it
<mbj>
solnic: I still think we are in sync, just focusing on differend aspecs in our communication.
<mbj>
gra{b,p}
<solnic>
I’m not sure :D
<mbj>
ttyl
mbj has quit [Quit: leaving]
<snusnu>
solnic: i'm gonna grab some food too … have a nice evening!
<solnic>
snusnu: you too!
snusnu has quit [Quit: Leaving.]
bf4 has joined #rom-rb
skade has quit [Read error: Operation timed out]
postmodern has joined #rom-rb
mbj has joined #rom-rb
<mbj>
solnic: How you'd like to identify mutations that could be ignored?
<mbj>
solnic: each mutation has a code witch is somehow deterministic
<mbj>
solnic: I could make it fully deterministic
<mbj>
solnic: Than you could do --ignore-mutation code:fooo
<mbj>
solnic: And I'd parse config/mutant.yml (not the default location!) from mutant directly
<mbj>
solnic: So need for hacking aorund in task/mutant.reek