开云体育

A consumer must be told the specific semantics to expect. One way is to read the code. In the absence of code you must rely on documentation. Executable documentation in the form of code examples that

I tend to program in a more functional style these days, so you can write much more concise, if-less code ... if you want your data in a collection to be "valid", for example, you flatMap over it and

Thanks John. Well I don't have to imagine it, I've seen which is what led to the question. :) Interesting perspective on contracts and the requirement to pass "correct" inputs (avoiding the use of

Think in terms of the contract between the caller and the code. The code guarantees valid results, ONLY IF the caller guarantees they'll pass in valid parameters. So if passing a null is not part of

Donald - If a test passes in the wrong input and fails initially, I see 3 general ways of getting the test to pass: 1. Have your test look for the exception that will be thrown by the code 2.

Eb, I agree with Colin in principle, but wider than that I'd say, following Uncle Bob's rule of "no code without a failing test" pretty well ensures you will have tests which supply incorrect inputs,

Thanks for your responses. Colin - what if another developer would be using it (and not the originally creator). How does he/she know that passing in null (for example) is wrong?

If this is internal code only and the code calling it is also testing then I not only would I not test it but I'd remove all defensive code guards as well. For example, a typical pattern would

It depends on the language, but in general, I think it should be tested. brought to you by the letters A, V, and I and the number 47

Hello everyone - I'm curious to know thoughts on writing tests that specify the behavior of a method when its inputs are incorrect. Is this a common practice. How about parameter validation in this

Good! :) 2013/7/25 Joakim Karlsson <joakim@...> -- Osias, o Osias [Non-text portions of this message have been removed]

Although there are an abundance of unit testing frameworks for C++ out there, I decided to learn some of the features available in C++11 by writing yet another one. At this point it's mostly for play

George - Answer is clearer and I am reminded of the two (complimentary) approaches. Thanks. <lists@...>wrote:

Eb, I tend to use a state-based approach (aka "Detroit style") so I'm usually verifying the result of the behavior. Often my test doubles are simple fakes (data sources) or stubs (data sinks, but

Thanks George. I am following that advice also (already) so very good to get affirmation of that. However, I realize my question was not clear enough so continuing from your answer, do you always

Eb, I wouldn't do that. I use adapters for third-party collaborators and mock my adapters to verify behavior. I also write integration tests for the adapter's interaction with the third-party. Steve

Hi everyone - What criteria do you use to determine if a collaborator that is a third-party should be mocked and the test should verify that the collaborator was indeed called when it was supposed to

There is a practice called "bebugging" (not a typo) in which developers deliberately seed the program with known bugs. The presumption is that testers will find them at about the same rate as unknown

I remember reading that NASA projects would not be released until a certain number of bugs had been found. This number was based on the project size and compared against bug statistics gathered

--- Keith Ray <keith.ray@...> wrote: That would, of course, inspire me to insert this gem every X number of lines: System.exit(-1) // TODO: Find and remove this "bug" during code review. . . OK;