On 4 Oct 2015 21:53, "Stephen Cameron" <steve.cameron...@gmail.com> wrote: > > > What I read from Martin Fowler is that a Mock framework, or that approach > in general, is different to traditional TDD in that it allows you to test > the behaviour of the system better. >
The book I recommend to understand mocks is "Growing Object - Oriented Software", by Nat Pryce and Steve Freeman. These guys wrote JMock and developed many of the concepts. Mocking was Pryce's PhD thesis, IIRC. At any rate, if you read his writings he talks about mocks as being the mechanism by which the communication protocol between (usually, two) collaborators is documented /defined. > What I perceive is that with a dependency injection framework, this > capability is limited, you can only pass a Mocked container to the first > object in a sequence easily, if that object calls other objects, which also > need to access the container for dependencies (e.g. domain services to > create new objects), then things are not simple. First point to make is that we only use mocks within unit tests, when we want to fake out all other parts of the system. For integration tests we don't do mocking at all. Second, when we do inject a mock, then we don't need to worry about the original implementation's own collaborators, so the point you raise is a non - issue. For example, suppose we inject an OrderRepository into a Customer entity,eg so that the Customer can query for old Orders. On the real implementation the OrderRepository will delegate in turn to the DomainObjectContainer, but in the unit test with the mock we don't care about that... we care only about the interaction between the Customer and the OrderRepository. We can therefore easily write unit tests for the case when there are no old Orders, or multiple old Orders, or whatever. > Regarding RAD, it seems that with an IDE you can design your object model > in the process of building your tests. If I define a sequence of > interations between objects (the message passing analogy) in my Mock test > sequence, then each new object method needed can be quickly added to the > respective object class definition. > Or an alternative, which we are thinking of using more and more, is to use contributed actions everywhere. See the incodehq/incode-module-note for an example... the actions on Note are actually all contributed actions, even though ask the functionality is in the same module. > A nice programming workflow would seem to be: create the mocked sequences, > in the process define the object methods, implement the methods, with unit > tests as needed if involve complexity (over and above get/set) > > This seems to me to be fully TDD. When I write OO code without tests a UML > sequence diagram is mostly what I am thinking of, either a mental one or > one on paper. By adding Mocks I can speadily get this design into a coded > form as a mock test and then implement the details, its going from the big > picture down to the small. Without such an approach I would work the other > way, building upwards to get a complete working system, before being able > see, and refactor, the behaviour I want. > Yep, what you are describing is a lot like the GOOS book describes. > So, a question is: Is this already possible? It is, though I admit I don't find myself doing it in practice, at least not with Isis. Rather, I tend to prototype in order to experiment with different design ideas / object responsibilities, then rusty up and put the formal tests in later. If I can get away with just integ tests, then I do... but i use mocks and unit tests for any bits of code that are more algorithmic in nature. Not sure what I describe above is best practice... there are risks in doing things that way, but it generally works out ok for me. > If not, then maybe the solution is to create something like the wrap > method, one that turns the Apache Isis DI container itself into a Mock > framework? At the minimum this would abstract all the datanucleus calls and > allow me to define the order of creation of all new objects as an > expectation. > Not sure I exactly follow, but in any case don't think it's needed. > A small question re the RAD Race (Dan/Jeroen), was the support for XLS > provided by Datanucleus not sufficient to use for loading of fixtures > directly from the spreadsheets? Maybe mapping was the problem? > We didn't explore that. However, as things are set up currently, DN had only one Store implementation, so one needs to choose between spreadsheet vs RDBMS. I suppose one could imagine some sort of federated Store implementation, but it seems like a lot of engineering just to be able to read a spreadsheet. Hth, Dan. > Regards > Steve Cameron
