The really nice to have is where the tests and the documentation are unified, making it impossible for them to diverge. That's what we've built our process around, and it works amazingly well.
Interesting. Can you expand on this?
Since code and comprehensible english are difficult to converge, what you usually wind up with in such a system is the story/test model.
The story describes the functionality in English (describes the user activity being modeled). The test then implements the story, preferably in a high level language where the story -> test translation is as trivial as possible. Here's a trivial story / test combination:
Story: The user logs in and logs out. The user is at the logout page.
The key to such a system is that the story/test are either in the same system, or very tightly coupled. In our system, there are hyperlinks from story to test and back that understand how to navigate our source control / build / documentation system so that you can easily go from story to test to test result and back again.
Either you misunderstood my post, or you have a fundamental misunderstanding of the halting problem.
It says that no algorithm can decide in general whether or not a given program / input pair will halt or not. The emphasis on the in general is the key.
It is actually trivial to do in many, many specific cases.
Because I know the difference and can make an informed decision about which to use? I've only once employed a proof of correctness, I use testing every day. The time we needed a proof there were hundreds of billions of dollars at stake.
The really nice to have is where the tests and the documentation are unified, making it impossible for them to diverge. That's what we've built our process around, and it works amazingly well.
No, testing verifies that your code works under certain conditions. A proof that your code is correct demonstrates that your code works under all conditions in a mathematically rigorous way.
Carefully instantiated variables that are never used are often changing global state. Having the variable makes debugging easier in some contexts. Not to say this is the explanation for your situation, but it is a reason you'll see that some times.
Try rendering out enough hidden information in your html such that a programmatic test can drive the UI in a meaningful way (ie unique, tree-based ids for every user manipulateable element). Then testing is just a matter of recording the path of interest through the application. A script where I work might look something like:
I'd like to give you my vote on your post and add a comment:
Get a second opinion. You will be shocked at how often two doctors disagree on what might seem to be simple diagnoses, meaning that at least one of them is just quite simply WRONG.
Doctors get it wrong a little more than three quarters of the time in my experience.
What makes you think the dialogue and details were faked rather than scripted? I mean, in a country with no free speech, you can tell your astronauts precisely what they are going to say and do. It makes writing the press announcements ahead of time quite reasonable. If someone deviates, you kill them. It discourages the rest. Really, it's all quite efficient.
But surely they would in a non-democratic country with no free speech where the country is quite legally allowed to tell the astronauts EXACTLY what they are going to say?
And if he had documented his code, explaining the performance advantages, you'd have read it in an hour and reached the same goal, and he wouldn't have dozens of WTFs to his credit.
Re:I really want a copy of this...
on
Clean Code
·
· Score: 5, Funny
If you could clarify which part I was wrong about, that would help. Your point was really tangential to mine, since I didn't talk about influencing others' actions, but rather self actualization.
If I had wanted to make your point, perhaps I should have gone with something like: it is impossible for one to acquire substantial wealth without exploitation, which most people agree is morally repellent.
Slashdot Mirror
The really nice to have is where the tests and the documentation are unified, making it impossible for them to diverge. That's what we've built our process around, and it works amazingly well.
Interesting. Can you expand on this?
Since code and comprehensible english are difficult to converge, what you usually wind up with in such a system is the story/test model.
The story describes the functionality in English (describes the user activity being modeled). The test then implements the story, preferably in a high level language where the story -> test translation is as trivial as possible. Here's a trivial story / test combination:
Story:
The user logs in and logs out. The user is at the logout page.
Test:
login
logout
assertTrue(currentPage == logoutPage)
The key to such a system is that the story/test are either in the same system, or very tightly coupled. In our system, there are hyperlinks from story to test and back that understand how to navigate our source control / build / documentation system so that you can easily go from story to test to test result and back again.
If you can define correctly, you can almost certainly prove it. :-)
I will personally guarantee to you that they are not cancergnous.
Either you misunderstood my post, or you have a fundamental misunderstanding of the halting problem.
It says that no algorithm can decide in general whether or not a given program / input pair will halt or not. The emphasis on the in general is the key.
It is actually trivial to do in many, many specific cases.
http://en.wikipedia.org/wiki/Halting_problem
In particular, take note of the second sentence:
Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist.
(emphasis mine)
Because I know the difference and can make an informed decision about which to use? I've only once employed a proof of correctness, I use testing every day. The time we needed a proof there were hundreds of billions of dollars at stake.
You use the right tool for the job.
I'm describing a UI level unit test (a test which covers a minimal unit of UI).
If you just want to test your widgets on an individual basis, just use selenium and test pages.
That's the only two facets to web testing I can think of, so if it isn't one of those please explain what you mean. Are you thinking of load testing?
The really nice to have is where the tests and the documentation are unified, making it impossible for them to diverge. That's what we've built our process around, and it works amazingly well.
No, testing verifies that your code works under certain conditions. A proof that your code is correct demonstrates that your code works under all conditions in a mathematically rigorous way.
Ok, maybe you were joking, but tenet was not the part of his post that was wrong/confusing, but it was wrong/confusing in yours:
http://www.merriam-webster.com/dictionary/tenet
http://www.merriam-webster.com/dictionary/tenant
Carefully instantiated variables that are never used are often changing global state. Having the variable makes debugging easier in some contexts. Not to say this is the explanation for your situation, but it is a reason you'll see that some times.
Try rendering out enough hidden information in your html such that a programmatic test can drive the UI in a meaningful way (ie unique, tree-based ids for every user manipulateable element). Then testing is just a matter of recording the path of interest through the application. A script where I work might look something like:
startpage = login .ClickRevokePrivileges
AdminPage = startpage.clickAdminTab
selectedUserRow = AdminPage.UsersList.SelectRandomUser
selectedUserRow
assertFalse(selectedUserRow.hasPriviliges)
You can imagine how each of those things maps to the relevant html.
Not clones. Clones may have only a mother (we can't do father-only yet .. but we're close).
I think the goal here is to give some funding to profit-losing ideas that help people. It's not hard to get profit-making ideas funded.
Did you read my post? I said my experience. That's tens of doctors across 100s of diagnoses.
I'd like to give you my vote on your post and add a comment:
Get a second opinion. You will be shocked at how often two doctors disagree on what might seem to be simple diagnoses, meaning that at least one of them is just quite simply WRONG.
Doctors get it wrong a little more than three quarters of the time in my experience.
Vested interest does not necessarily lead to bias, though it certainly could have done so in this case.
Dude, you're arguing with yourself, get help!
They transported it from Arizona by truck. Duh.
What makes you think the dialogue and details were faked rather than scripted? I mean, in a country with no free speech, you can tell your astronauts precisely what they are going to say and do. It makes writing the press announcements ahead of time quite reasonable. If someone deviates, you kill them. It discourages the rest. Really, it's all quite efficient.
But surely they would in a non-democratic country with no free speech where the country is quite legally allowed to tell the astronauts EXACTLY what they are going to say?
I always assumed such ethics codes were an attempt to improve life for the rest of us.
And if he had documented his code, explaining the performance advantages, you'd have read it in an hour and reached the same goal, and he wouldn't have dozens of WTFs to his credit.
Mod parent redundant, gp already said 'Use Perl!'
If you could clarify which part I was wrong about, that would help. Your point was really tangential to mine, since I didn't talk about influencing others' actions, but rather self actualization.
If I had wanted to make your point, perhaps I should have gone with something like: it is impossible for one to acquire substantial wealth without exploitation, which most people agree is morally repellent.
I think the president is doing quite well (at enriching himself, at least). Was that not clearly the point of my post?