51

Re: Pluses of the best methodologies a testing unit.

52

Re: Pluses of the best methodologies a testing unit.

Hello, Sharov, you wrote: S> to Develop, that it was scaled for millions users simply? Angry birds too it is not easy to make, if that. And what there "it is scaled for millions users" in Angry birds?... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

53

Re: Pluses of the best methodologies a testing unit.

Hello, CoderMonkey, you wrote: CM> And what there "is scaled for millions users" in Angry birds? Not correctly understood - or-or. I.e. any service for millions  it is not simple. And standalone mobile application that millions to hook, develop not simply. Though in both cases of special complexities can and not to be. The nobility well tool and technologies, and the nobility of need of the market.

54

Re: Pluses of the best methodologies a testing unit.

55

Re: Pluses of the best methodologies a testing unit.

Hello, Sharov, you wrote: S> and the nobility of need of the market. That's it here the dog also rummaged. Where now Smolltok, for example? Or where Amiga? They knew technologies perfectly, and here could not sell.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

56

Re: Pluses of the best methodologies a testing unit.

57

Re: Pluses of the best methodologies a testing unit.

Hello, CoderMonkey, you wrote: CM> That's it here the dog also rummaged. Where now Smolltok, for example? Or where Amiga? CM> they knew Technologies perfectly, and here could not sell. Well and? If at someone it did not turn out, does not mean that at all it does not turn out. There will be people who make and sell.

58

Re: Pluses of the best methodologies a testing unit.

Hello, CoderMonkey, you wrote: CM> And me for some reason it seems that between hello world and the monster of type  there are many intermediate stages. And the majority of these "stages" - operation in collective. The same  is today a banal command development.

59

Re: Pluses of the best methodologies a testing unit.

Hello, Sharov, you wrote: S> For the sake of justice, all engines for something, . actively to use . A floor-mat. The device. Very few people can make. Here there are singletons, and it really happens difficultly. Especially to understand the code. Well again , singletons can unless a kernel to write. And to finish idea to a ready product -  again collective operation.

60

Re: Pluses of the best methodologies a testing unit.

61

Re: Pluses of the best methodologies a testing unit.

Hello, Sharov, you wrote: S> Well and? If at someone it did not turn out, does not mean that at all it does not turn out. There will be people who make and sell. It means that ability to untwist the project is a question , instead of programming. And it is possible to untwist also the full shit as happened more than once.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

62

Re: Pluses of the best methodologies a testing unit.

Hello, itslave, you wrote: I> And the majority of these "stages" - operation in collective. The same  is today a banal command development. As a rule, it is simple because the manager with a small command is simply full sucker in the opinion of other managers... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

63

Re: Pluses of the best methodologies a testing unit.

Hello, CoderMonkey, you wrote: CM> As a rule, it is simple because the manager with a small command is simply full sucker in the opinion of other managers Yes take any successful  a product - everywhere commands.

64

Re: Pluses of the best methodologies a testing unit.

Hello, CoderMonkey, you wrote: CM> Not suddenly. One does not suffice only when you need to write something absolutely . It , or you hello world did not write anything else never?

65

Re: Pluses of the best methodologies a testing unit.

Hello, itslave, you wrote: I> It , or you hello world did not write anything else never? I - wrote, and I write. And you really think, what you the best programmer in the world and are better than you anybody cannot?... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

66

Re: Pluses of the best methodologies a testing unit.

Hello, itslave, you wrote: I> Yes take any successful  a product - everywhere commands.  saw normally as a hobby (that is time for it very little), or it is the most normal project with managers, only  .... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

67

Re: Pluses of the best methodologies a testing unit.

Hello, CoderMonkey, you wrote: CM> I - wrote, and I write.... Projects  with hello world. CM> And you really think, what you the best programmer in the world and are better than you anybody cannot? I in general that at all absolutely the programmer already, well  the such. The main thing - you without  in any way.

68

Re: Pluses of the best methodologies a testing unit.

Hello, CoderMonkey, you wrote: CM> Opensors saw normally as a hobby (that is time for it very little), or it is the most normal project with managers, only  .  where look - everywhere at malicious managers which sleep and see   to itself of a command. Do not allow to be torn to geniuses-singles, most likely self-educated persons.

69

Re: Pluses of the best methodologies a testing unit.

70

Re: Pluses of the best methodologies a testing unit.

Hello, netch80, you wrote: N> For the sad glue code of type "to take a forcemeat ball, to dip in crackers and  on a frying pan" which majority even in quite interesting projects, units-tests will be only  code lines without real favor. It is categorically not consent. Units-tests FORCE to write the code so that it was easy for testing. And it essentially refines architecture as DI and SRP follow practically automatically. And rarely it turns out to do integration tests universal, especially at testing of responses for such things as internal failures and violations of integrity of the data.

71

Re: Pluses of the best methodologies a testing unit.

72

Re: Pluses of the best methodologies a testing unit.

73

Re: Pluses of the best methodologies a testing unit.

74

Re: Pluses of the best methodologies a testing unit.

Hello, Vedmed, you wrote:>>> it is simple because about a unit tests the majority of bugs not cunningly would transit the first . CM>>> the Garbage. Tests any a unit guarantee nothing, as from errors of understanding  do not rescue, and even for more primitive bugs too guarantee nothing, as can contain errors. N>> well against such situations there is a method to demand writing of tests not the author of the code, namely QC employees. N>>Jef239@habr persistently recommended such variant also because testers much more cheaply. ؼ. As it seems to me here there is a confusion between the functional autotests and . The functional autotests should write just QA, and a unit tests authors of the code. Not that that confusion, but Jef239 them, seemingly, in essence here did not divide. At level of one function both set are reduced to result check at specific arguments. The difference goes in other (further I describe in the core already with a support on the experience): All similar tests are accurately enough divided into check of typical cases and scenarios, and check of marginal variants. For example, if we write multiplication of 16-bit numbers typical will be 0*0 and 2*2, and marginal - (-32768 *2. And the estimation of both sets of typical and marginal variants can be noticeable various between actually author of the code and an exterior tester: the exterior writes on  (likely, it and is yours "the functional autotests"), and the author is obliged to consider implementation because for him nobody makes it. And here if the exterior tester starts to guess about internal implementation - here it always confused me in the described approach (here already again not on the experience because I just fulfilled marginal cases itself, how many they saw). The functional tests on  become on system as on a black box, a unit tests for a system part as on a white box (moreover with  without a surrounding) Here I and I speak - such sharing suspiciously rigid. In a reality in between there is a natural noticeable overlapping. I at all do not accept separation of units-tests from the functional: it only the lowermost level of functional (and integration - upper), and it it is possible to understand units-tests when you find out what to test the subblock as "a black box" both it is more important, and is more effective, than to try  it not only outside, but also from within.

75

Re: Pluses of the best methodologies a testing unit.

Hello, CoderMonkey, you wrote: N>> Well against such situations there is a method to demand writing of tests not the author of the code, namely QC employees. N>>Jef239@habr persistently recommended such variant also because testers much more cheaply. CM> All the same the garbage because 1) errors can be immediate in  If is explicit contradictions, they should be opened at analysis stage . If the customer inscribed in  such that the executor cannot check up, it outside of considered problems. CM> 2) the probability of errors in tests at such approach becomes still above. That it? CM> and still there are various not determined errors against which units-tests too are absolutely useless. So I do not deny importance of the functional tests more high level. But against floating errors and they are not so useful, if in addition are not supplied with techniques of search of such errors.