Language:
switch to room list switch to menu My folders
Go to page: First ... 34 35 36 37 [38] 39 40 41 42 ... Last
[#] Mon Sep 14 2009 13:48:30 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

So all this is about, is writing a harness to test all of those
branches that you're already testing manually - it'll probably take
about the same amount of time as what you're doing now to do the
initial implementation, ***and then you can re-run the whole suite

Yes and no. I'm a lot faster with my debugger than writing test scripts, which is why I do it that way.
And the other problem is, even if I wrote the script, I'd have to run it in the debugger anyway, just to make sure the script is doing what I expect it to. That's how I am. I just can't write software without doing that.

[#] Mon Sep 14 2009 13:49:54 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

There's one guy still resistant to the idea of telling the sysadmins

that he's changing things in production.

The sysadmins?!? What about QA??

[#] Mon Sep 14 2009 13:51:05 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That's just pci. We don't have any other auditors that I know of. And

after that episode I think we're going to design our product line
around avoiding auditors.

Electric shocks through the keyboard, eh? I've always wanted that feature.

[#] Mon Sep 14 2009 13:54:54 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

And the other problem is, even if I wrote the script, I'd have to run

it in the debugger anyway, just to make sure the script is doing what I

expect it to. That's how I am. I just can't write software without
doing that.

Erm, you should really look into tools like Cobertura. It does the same thing as your debugger (tells you whether the branches were taken) without all the manual-ness of the process, and it does so in a much more rigorous, repeatable fashion. If you start really putting this into practice, you'll probably realize the debugger just isn't necessary and you'll focus all your testing on two areas: (1) unit testing scripts, and (2) quick and dirty functional testing that just covers the major use cases, and not all the errors and validations and bulletproofed blast armor.

[#] Mon Sep 14 2009 14:48:01 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

The sysadmins?!? What about QA??

We don't have a qa department.

[#] Mon Sep 14 2009 14:49:37 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

into practice, you'll probably realize the debugger just isn't
necessary and you'll focus all your testing on two areas: (1) unit

erm... "debugger isn't neccesary" doesn't compute in my universe. I am a new level of control freak most people have not met before.

[#] Mon Sep 14 2009 14:55:55 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I only occasionally get to write code that tests my code. I find it's wise to do this with the bottom layer stuff... the stuff that absolutely has to be rock-solid or the rest of the house of cards tumbles.

The higher-level stuff... the stuff that's closer to the user... that doesn't seem to need it as much. When an error happens there, it's obvious, and more easily correctable.

In this way, I don't waste as much time.

The test code that you use for automated testing is best for finding problems during regression anyway. And I guess you probably only really need that if your product has become so big that a small change here could lead to something radical somewhere else.

[#] Mon Sep 14 2009 15:36:27 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

We don't have a qa department.

all the more reason to automate all the tests you can

[#] Mon Sep 14 2009 16:16:47 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

gcov is the C way. it sure needed to revalidate a unit test.

The unit test has one real _big_ advantage once you need to change components covered with it.

I guess its gonna outperform you and your debugger a little, Ford.



[#] Mon Sep 14 2009 16:22:44 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sep 14 2009 4:16pm from dothebart @uncnsrd
gcov is the C way. it sure needed to revalidate a unit test.

gcov is great from what I can tell. It gives you line coverage, basic block coverage (which is just a variant of line coverage) and most importantly, branch coverage.

Then you have lcov, which is just a perl script to pretty-format the gcov results in HTML. But they "lost" their code that implemented branch coverage... bah!

Branch coverage reports are great for analysis, but they sort of encourage sneaky programmer behavior like hiding your logic in subroutines just to avoid writing fully-truth-tabled (I'm gonna use that as a verb, just try and stop me) test cases and still have your coverage reports appear to be 100% ;)

[#] Mon Sep 14 2009 16:23:28 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


of course line coverage encourages its own sneakiness: put the "if" and the "then" all on one line, and voila, your coverage goes to 100;)

[#] Mon Sep 14 2009 20:26:34 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

The unit test has one real _big_ advantage once you need to change components

covered with it.

I guess its gonna outperform you and your debugger a little, Ford.

Yes, you must have skipped that part of the conversation.

[#] Tue Sep 15 2009 10:33:40 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Is it common (or even accepted) to put some unit tests directly into the build script, so that a failed unit test shocks the developer as the same level as "it doesn't build" ?

[#] Tue Sep 15 2009 11:53:29 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


IG, it goes into the build script but it's never run by default, always "make test" (or similar).

[#] Tue Sep 15 2009 11:58:47 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I mean, if you want to piss off your developers, than sure. In reality, none but the most trivial unit tests are going to achieve the level of performance where that would go unnoticed.

High performance unit tests are essential though. In fact, your unit test performance is more important than your code performance! Write tests before you code! Write tests INSTEAD of code! Oh wait a minute.


Got carried away there.

Seriously though, if you want reasonable unit test performance, fast enough to encourage developers to run the tests on their own machines, you have no choice but to abstract the database stuff. (Network, disk, and database thousands of times slow than CPU and RAM, etc, so you need to be able to exclude it from the majority of test cases.) I've attempted to do otherwise, and watched it fail in myriad ways.

[#] Wed Sep 16 2009 10:38:26 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html

new stuff from apple...

Grand central & Blocks;

blocks seem to be function pointers with some tiny additions; Local variables remain the same for them while it changes for the rest of the system.

I'm not yet all fammiliar with what its doing, but it seems to be some different aproach to critical sections to multi-core enable programs...

 



[#] Fri Sep 18 2009 15:35:07 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sep 16 2009 10:38am from dothebart @uncnsrd
http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html

Sounds like Ford's "smart pointer" all over again. What was the smart pointer theorem? Something like, every programming environment will eventually degrade in design until it sucks so hard that somebody invents the smart pointer?

[#] Fri Sep 18 2009 16:44:23 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Oh no. Anonymous code blocks in C.
They're really lost sight of what the point of C was, haven't they.
At least the syntax isn't as ugly as objective C. That whole departure really bothers me for some reason.

[#] Fri Sep 18 2009 16:47:36 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Okay, I haven't even gotten to the second section yet.
Why do you have to reference count or even allocate a code block. A code block in C (I hope to hell...) is static binary data. Why would you ever have to allocate it or not. The only thing you'd need to allocate is space for local variables and whatnot.
I like that line "Unlike Objective C, C++ doesn't have a standard reference counting mechanism." Like C++ is in some way inferior to OC? Nice try.

[#] Fri Sep 18 2009 16:49:32 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Okay, now I see what you mean by "everying will eventually devolve in to a piece of shit."
C held out for a good long time, but I guess its time has come.

Go to page: First ... 34 35 36 37 [38] 39 40 41 42 ... Last