Now, I don't normally make a post like this, but I am sick of it…
Apparently, the Paludis folk, have knowingly sat on a pkgcore bug simply because “we wanted them to write unit tests to find it rather than actually tell what the bug is.” (paraphrased) – When you constantly claim you are trying to work “together” and then blatantly do something that isn’t, it makes you look like more of an idiot. There is another company out there that does something similar. Not many people like them either.
It’s been a while since I’ve posted anything, I hope to put something more substantial and less annoying up soon.
Edited to remove offensive content, and I do apologise to ferdy for not thinking before just shooting off random drivel on my blog.
Which company are you referring too? I didn’t know there was a company out there who promoted writing solid, good software by trying to convince other people that basic comp.sci. knowledge like *always writing unit tests* was a good idea.
You know, give a man a fish and you feed him for a day, teach a man to fish and you feed him for a lifetime.
@Ian:
One fault here is the bit of slander the paludis folk are pushing that there are no unit tests. Few fun stats; roughly 25% of pkgcore distributed source (line count wise) is actually tests.
Portage, under 1/36th the source (the percentile is actually lower, I’m just too lazy to fold in their misc scripts that aren’t picked up by a simple find, ratio won’t improve if I made it more accurate after all).
Paludis, roughly 23185 out of 137340. Above 16%, roughly.
So yeah… we actually believe in unit tests. One thing we follow is testing the *hell* out of a component- a quicky “try a few things with it” test isn’t what we do, we go for completeness w/ each set of tests primarily to avoid the common fallacy unit tests fanatics have- that if there is a test, everything must work (regardless of how complete that test might be). Basically the schism between having tests, and what the actual coverage of the tests is.
Bash side of pkgcore currently, is mostly untested- why? Because what’s there is going to be ripped out, and because (frankly) I’ve not gotten around to doing full tests for it.
I’d point out that the area they’re complaining about (EAPI1) is also under a decent set of tests- not complete atm, but that’s a far difference from “learn to write unit tests” as they’ve tried implying.
Cheers.
Slight correction to my statements from above- percentile I posted for paludis is accurate, the numbers I pasted in however were from an early scan. Approximate stats being 33622 loc for tests, 170750 loc nontest- meaning % of distributed code that is tests (the metric used above) is 33622/(170750+33622) == 16.4%. Like I said, percentile stated is accurate, but I didn’t supply the correct numbers that results in it.
This is also assuming I picked up all nontest paludis code via the find also (I’m fairly sure I didn’t), so the percentile is likely slightly lower, although I’d presume still above 16% however primarily due to the fact they’ve got over 200kloc of code (missing a few thousand here and there isn’t going to shift the stat that much).
At least for pkgcore, knowing the source rather well, the stat that there is pretty much dead on also.
Ferringb, counting lines is hardly useful as I’m sure you’d agree.
What matters is how much is covered by the unit tests and if the tests are covering the right things. Having a test that shows something like print(“Hello World”); spits out a string might be fun but if you’re trying to test that print works as expected you want to make sure it’s the string it spits out and not just any string.
So why are you counting lines when it doesn’t matter?
> So yeah… we actually believe in unit tests. One thing we follow is testing the *hell* out of a component
I have a present for you: http://zlin.dk/p/?YTcwYmJj
Maybe it’ll help you to test said hell out of your version comparison code.
You might also like to reconsider the logic in http://tinyurl.com/6r3aqc (perhaps the output of the previous script will give you a hint).
ferringb, I’m not sure I’d brag about the amount of tests in my software if for all the testing I still failed to cover the EAPI 1 completely.
Guys, stop backtracking.
First you claim that there’s no tests. You get some proof that the statement is incorrect and you shift to “but they don’t test anything relevant”. Next you’ll say “Yes, ok, they do, but they are not written with the right (paradigm|strategy|vision|…)”
You fail.
RandomGuy – if you refer to my comments you’re very, very wrong. I’ve never stated that pkgcore have no tests (and I wouldn’t really know either as I don’t follow pkgcore development at all).
I just responded to the comment about counting lines as I see that as avoiding the subject somewhat.
Heck, for all I know pkgcore could have absolutely brilliant unit tests (ok, ferringb said there’s hardly any tests for the bash parts but the rest of it could be covered fairly well for all I know). But counting lines is extremely silly as that doesn’t say anything about coverage or correctness and that’s what I pointed out.
Now, if somebody could show me how much code is actually covered by these tests and how many codepaths is tested.. that might impress me.
> First you claim that there’s no tests. You get some proof that the statement is
> incorrect and you shift to “but they don’t test anything relevant”. Next you’ll say
> “Yes, ok, they do, but they are not written with the right
> (paradigm|strategy|vision|…)”
Nobody said, that they don’t test anything.
The complain was, that there are some tests missing.
Bear in mind that you need something like five times the number of tests to test Python code than you do to test C++ code, if only because there’re so many errors you can make the C++ compiler catch that with Python can only be caught at runtime. Have a look at the ‘raw stat in CONTENTS’ bug for a typical example of that…
Curry-Howard isomorphism basically says that you can transform any bug in your code into a bug in your type system…
>Bear in mind that you need something like five times the number of tests to test Python code than you do to test C++ code
Conjecture, what is the basis for that statement outside rectal extraction?
>if only because there’re so many errors you can make the C++ compiler catch that with Python can only be caught at runtime.
That’s why you code defensively and wrap everything in exceptions. Not a formalism you recognize, but it works quite well.
> Curry-Howard isomorphism basically says that you can transform any bug in your code into a bug in your type system…
Right, so where’s the design document for paludis? Where’s the formal proof of correctness? What, you only cook with water like everyone else? I thought so. And please stop using Big Words in the hopes of confusing enough people …