2016-10-28 21:07 GMT+02:00 Guillermo Polito <[email protected]>:
> And again i'll hold my position: whoever wants to load it can do it. There >>> is no need to put it there by default. >>> >> Do you know how much easier it would be to design and test FileSystem >> with mocks. Code and tests will be much better and simpler from the >> beginning. >> And I could said it about any package which provide abstractions. >> > >> Now no project which is part of Pharo can use mocks for tests. So it is >> not question of loading it for own project. Pharo contributors can't use >> mocks. >> > > That is not true. People can create mocks by hand. They do not require a > library for easing it. Maybe it is a bit more bureaucratic but it still > works. > Come on, get real. It is not practical sentence. It is *one of* the reason of bad quality and amount of tests in system. People just not write tests when it is difficult. And building custom mock classes is supper slow and boring which moves you away from actual business problems. > > Second, mocks are no silver bullet. they are alright to decouple and try > to test some parts of the system in isolation, but then you still need > integration tests to test how the different components add-up together. > It is all valid and not against any of my point. > >> And there is another story. Imaging Ruby guys join Pharo development (not >> real story :)). Many years In Ruby people use mocks and "human should" >> assertions. >> > > Ruby guys can load the library they prefer. And use it in their projects. > I'm no-one to forbid that, and actually I'd encourage it if that is what > they want. > And when Ruby guy will want to contribute to Pharo you will say him "build mocks by your hands". And he will say many nice words about TDD in Pharo. > > And actually this is what they do in Ruby: if they want a library they > load it. Why in Pharo it cannot be the same for god's sake?? > > Most TDD evolution was from Ruby. I imaging their impression about Pharo >> "the best for TDD". >> > > TDD is not about mocks. TDD is not about tests. TDD is about a way to > approach the design of an application. > Exactly. We all know it. But look at system. Nothing is designed by TDD. Most tests are written after code. And most tests are high level acceptance tests. > And what makes Pharo IMHO "the best for TDD" are not mocks but the > debugger and how we can develop applications with it. > As you said TDD is about design. First we specify design decisions in test. And only then we start implement them. So debugger is only about second part. And Pharo here is the best. But writing specifications in tests is quite limited without advanced mock library. Limited in practical sense. It should be maximum simple technically: if your real object is hard to setup or you not have one then just get mock with minimal effort. Without it TDD process is always interrupted by non business problems. > > >> And generally I would said we have quite bad tests in system. They are >> slow, they corrupt image. Mocks will help to improve this situation. >> > > Yes, but that's not because we do not have mocks. That's because some part > of the system are not designed to be tested (depend on global state), or > because nobody cared of writing good tests. > > **I am 100% sure that people can write bad tests with any mock library > that you want** > And I am 100% sure that people can write spaghetti code with any language that you want. Why use Smalltalk then? P.S. nice post on TDD from Uncle Bob http://blog.cleancoder. com/uncle-bob/2016/03/19/GivingUpOnTDD.html
