In computer science, the term Mock Trainwreck refers to the difficulty of mocking a deeply nested model structure. Mocking is the creation of mock objects which can be used to mimic the behavior of real objects, often because it is hard to test with the real objects. A trainwreck is multiple levels of method calls (called a chain), which each return objects upon which new methods can be called. Deeply nested models go against the Law of Demeter because the property's property must be accessed. The Law of Demeter, also known as the principle of least knowledge is a design guideline to promote loose coupling of data structures that are not closely related, and thus should probably not be coupled together. In addition, this level of coupling can be considered an inappropriate intimacy code smell. Mock trainwrecks should be avoided when possible. This is because not only does it makes it harder to test the code which uses them, but also because they are harder to work with from a design standpoint. In addition, it increases the amount of information an object can access, due to its close relation with other parameters that are not related to its main functionality. Example of a trainwreck If someone wanted to write a test looking for a library that receives public funding, or by its head librarian, he or she might use code like the following: Java assertEqual( l.getHeadLibrarian() .getName().split(" ")[1] , "Smith") assertEqual( l.getFunding().getType() , "public") Ruby l.headLibrarian.name.split(/ +/).last.should == "Smith" l.funding.type.should == "public" To mock up an object that matches the search result, they would have to have mocking code like what follows: Java HeadLibrarian h = mock(HeadLibrarian.class); when(h.getName()).thenReturn("Jane Smith"); Funding f = mock(Funding.class); when(f.getType()).thenReturn("public"); Library l = mock(Library.class); when(l.getHeadLibrarian()).thenReturn(h); when(l.getFunding()).thenReturn(f);Rubyh = mock('HeadLibrarian', :name => 'Jane Smith') f = mock('Funding', :type => 'public') l = mock('Library', :HeadLibrarian => h, :Funding => f) This is an example of a mock trainwreck, because it is a mock up of two unrelated objects, but it relies on a class, Library, to point to them both. Ways to avoid the trainwreck A mock trainwreck can be avoided by making general code changes or by more specific changes through the use of dependency injection and libraries. General code changes allow a nested model to be made more simple, primarily though the creation of an assessor to access the sub property. This prevents the deep nesting which