I don't know that unit testing has been used that I am aware of in this system. I have been using it myself for some of my own code. The pain exists that building the source is hard because it uses auto generated wrappers around GNUStep objective C objects. This means that to build the Java requires a special build process using the GNUStep make system extensions. I cannot simply run my unit tests in the IDE because the IDE cannot build the source itself. I know it probably should be possible to set up running the unit tests from the command line after the source has been built externally. On Dec 21, 5:05 pm, Greg Reddin <[email protected]> wrote: > On Wed, Dec 21, 2011 at 6:24 AM, Carl Jokl <[email protected]> wrote: > > I have not come across someone who is against the model view > > controller pattern and so was not really prepared for that. I don't > > know what I should do or how I could better defend MVC. MVC to me > > improves cohesion of a system which each class having a well defined > > responsibility rather than big bloated classes where the classes > > contain model, view and controller functionality all mixed together. > > I think you are correct. I'll agree with others who have stated that > this is not specific to MVC. MVC is simply an attempt to keep the > proper separation of concerns. In your current system how do you > perform maintenance? IOW, how do you verify that one component is > working correctly as you make changes? A "0-layer" approach means you > pretty much have to wait till you're done coding it, fire up the > system in a test environment, and run it to see if it works. A layered > system allows you to build test cases for each part and test it > completely separate from anything else. This helps you to isolate > problems. It also helps you to have confidence when moving from one > thing to another that the thing you just wrote really works. > > In our world we've duplicated some demo data that we use for our unit > tests. We also use mock objects to imitate this data as it moves > through our system. So as we work on each piece we can work on it in > isolation and verify how it reacts to real world situations. We've > also built a good set of test cases over the last couple of years to > catch a lot of regressions. Now I can have confidence when I do a > refactor that, as long as the system still passes the set of test > cases we've built, the refactor is good. > > This is very difficult to do in a non-layered architecture. You really > can't have that kind of confidence as you're working. Developers then > don't really know how to estimate progress because they don't know how > far from being "done" they are with a task. So everything looks rosy > until the final few days before a release when no one can seem to get > anything to work. At least that's my experience. > > So my main arguments for separation of concerns are 1) confidence in > each piece in isolation, 2) better regression testing, 3) more > accurate progress reporting, which leads to 4) better project > management. > > If there's a downside to this approach it is that all the test cases > take a long time to write. However, I'd argue that it's still quicker > than blind debugging where you really don't know what affect your > changes are having until everything is done. The difference is that > you will learn to estimate the time it takes to write tests. You can't > estimate the time you'll spend fixing bugs. > > HTH, > Greg
-- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
