Discussions

News: Article: Is Software Becoming More Testable?

  1. Article: Is Software Becoming More Testable? (13 messages)

    It is clear that testing is becoming an important driver for design, despite degrees of tension. Alan West discusses how stored testing knowledge and automated checks and tests can increase framework testability.
    There is obviously a degree of tension between design and validation: The more standardized (and stable) a software design is the more possibility there is for test automation and innovation. But the more variation there is, the greater the possibility for design innovation. Obviously the situation is dynamic - new areas of software application naturally create a rash of competing approaches and frameworks. But in more established areas we could hope for greater standardization to allow testing to become better understood and automated. However the traditional lack of focus on testing in computer science has probably weighted the equation in the past towards continued fiddling and variation on designs to the detriment of the finished product; it's more fun that way.
    What, if any, innovative testing trends have you seen coinciding with design innovation?

    Threaded Messages (13)

  2. All the considerations in mind: scheduled release, functionality,budget, makes software a competetive weapon.Sometimes functionalities are sacrifised for budget and sometimes quality is sacrifised for timeline.Any way, no time is left for testing.May be this is the common scenario but in established areas, more time can be spent in standardization of design and development process so that Testability finds its proper place and can be performed in easy and automated manner. The design and offcourse its implementation which is standard, easy,controlable, stable and observable is always easily and effactively testable. cheers, http://javaicillusion.blogspot.com/
  3. Automated testing in XINS[ Go to top ]

    The XINS application framework has, over the years, developed several features to improve both manual and automated testing. Indeed this stems from the fact that the framework is based on a fairly high level of standardization, since it requires application interfaces to be described in an XML specification format. Below are some examples of the test-related features XINS offers. First of all, HTML documentation (example) is generated from this specification format. This HTML documentation contains test forms (example) for easy manual testing of applications. Secondly, XINS can automatically produce stubs (documentation), that behave exactly as the examples in the specifications specify. These are plain simple WAR files that can directly be deployed in any servlet container. Thirdly, the examples are also used to generate JUnit unit tests (documentation). These unit tests make appropriate HTTP calls and check that the results are as specified in the examples. They test both successful and unsuccessful cases. Finally, as of the upcoming XINS 1.5 release, JMeter configurations can also be generated with a single command, making it far easier to do load and performance testing. Another thing that can be very useful for frameworks is proper transaction logging. If transactions are logged completely (both input and output), then they could be translated to automated tests as well, but then with real-world data. These tests could be used for performance and load testing.
  4. Too much focus on testability[ Go to top ]

    Today we don't have frameworks that can be "unit testable" without thinking of it when designing. Unfortunatly most designer seem to think that it is ok to sacrifice Today we don't have frameworks that can be "unit testable" without thinking of it when designing. Unfortunately most designer seems to think that it is ok to sacrifice good business object design in favor of testability. That is why we have the horrible DAO pattern instead of using technologies like JDO, Hibernate and JPA. It is a common mantra so say that EJB (2.1) is bad especially entity beans. If developers had used them like objects with behavior there existence could be motivated. Up until recently I had always thought that most developers had a good knowledge of object orientation but now I think that perhaps less than 10% really understand OO. I clear indication of this is that entity bean (2.1) is accused of being complex and bloated when the real problem is its weak query language and lack of support for polymorphism.
  5. Re: Too much focus on testability[ Go to top ]

    Unfortunately most designer seems to think that it is ok to sacrifice good business object design in favor of testability. That is why we have the horrible DAO pattern instead of using technologies like JDO, Hibernate and JPA.
    I am rather puzzled as to how this conclusion is reached. The "horrible DAO pattern" is not bad at all, if there is real remoting between Client and Server. It is somewhat bizarre if performed within a JEE container, of course. And the prime reason for this pattern being popular is probably that Sun has published "patterns" which gave them a certain leverage as well as this "pattern" being totally ignorant of the actual storage mechanism (JDO,EJB,Hibernate,PlainSQL...).
  6. Re: Too much focus on testability[ Go to top ]

    The "horrible DAO pattern" is not bad at all, if there is real remoting between Client and Server.
    Such an abstraction often makes a lot of sense from a clean layering an OO perspective. Consider for example Eric Evan's Repository pattern in DDD. That is not driven by any framework.
  7. Re: Too much focus on testability[ Go to top ]

    this "pattern" being totally ignorant of the actual storage mechanism (JDO,EJB,Hibernate,PlainSQL...).
    Well there you have it. PlainSQL it not OO in anyway. DAO is using the least common denominator. What you end up with is just shuffeling data and is not using any of the good features of JDO, Hibernate etc.
  8. Re: Too much focus on testability[ Go to top ]

    this "pattern" being totally ignorant of the actual storage mechanism (JDO,EJB,Hibernate,PlainSQL...).

    Well there you have it. PlainSQL it not OO in anyway. DAO is using the least common denominator. What you end up with is just shuffeling data and is not using any of the good features of JDO, Hibernate etc.
    Dude, nothing is preventing you from using any and all best features of JDO, Hibernate, etc... The implementation of your DAO and/or Repository interfaces is completely up to you. I really don't know what you're advocating here, since the same can be said with using Hibernate or JDO, "Oh, but then you're not using any of the good features of JDBC". Actually, if you have a very well defined DAO layer, you can use the best features of everything, since your persistence framework is now abstracted behind an interface that implements a logic access to the persistence layer (use cases). Ilya
  9. Re: Too much focus on testability[ Go to top ]

    Unfortunately most designer seems to think that it is ok to sacrifice good business object design in favor of testability. That is why we have the horrible DAO pattern instead of using technologies like JDO, Hibernate and JPA.


    I am rather puzzled as to how this conclusion is reached. The "horrible DAO pattern" is not bad at all, if there is real remoting between Client and Server. It is somewhat bizarre if performed within a JEE container, of course. And the prime reason for this pattern being popular is probably that Sun has published "patterns" which gave them a certain leverage as well as this "pattern" being totally ignorant of the actual storage mechanism (JDO,EJB,Hibernate,PlainSQL...).
    Karl, why is it bizarre in a JEE container? Maybe I'm missing something. I mean, if you're not using JPA, rather using JEE container for other services, DAO is still a good option. Practically, we can also argue that DAO might be used to no necessarily abstract the storage mechanism, but rather to provide a persistent object interface, which is based on use cases. I think this is what the Repository layer is used for. I can't really distinguish the Repository vs. DAO layer for some reason, both seem to be an interface for persistent object access.
  10. Re: Too much focus on testability[ Go to top ]

    Today we don't have frameworks that can be "unit testable" without thinking of it when designing.
    Unfortunatly most designer seem to think that it is ok to sacrifice Today we don't have frameworks that can be "unit testable" without thinking of it when designing.
    Unfortunately most designer seems to think that it is ok to sacrifice good business object design in favor of testability. That is why we have the horrible DAO pattern instead of using technologies like JDO, Hibernate and JPA.
    It is a common mantra so say that EJB (2.1) is bad especially entity beans. If developers had used them like objects with behavior there existence could be motivated.
    Up until recently I had always thought that most developers had a good knowledge of object orientation but now I think that perhaps less than 10% really understand OO. I clear indication of this is that entity bean (2.1) is accused of being complex and bloated when the real problem is its weak query language and lack of support for polymorphism.
    Maybe it's the fact that you somehow misunderstand the disconnect between DAO and persistence technologies. Persistence frameworks are there as a generic way to persist your object, be it a relational store, or what ever else. They are generic, though the interfaces they provide are such. The DAO layer is there to encapsulate your db access use cases, they are not reflected as interfaces within the persistence mechanism, they are also there to abstract away your persistence related code, though giving you the ability to seperate your data access use cases, from a particular persistence technology. Ilya
  11. OK I am going to screw around here.[ Go to top ]

    Damn interface zelots.
  12. Automated Method Testing[ Go to top ]

    Perhaps the notion of "Automated Method Testing" helps advance the cause? Instead of custom coding unit tests concurrently with development - an automated method tester (written before the project is started) ensures method patterns are clarified. Clarified to the extent they can be in a "tested" without hand-written unit tests. A reference implementation for "Automated Method Testing" is at: http://gtcgroup.com/util/index.html _Marvin
  13. Languages are the culprit[ Go to top ]

    Yes, software is getting more testable, but the real problem is language design. Expect testability concerns to wane as people move to more dynamic languages. In Ruby, if a method gets in the way during test, you replace it.. on any class. In Java, C#, and C++ things are more difficult. Testability has to be a matter of design. Michael Feathers http://michaelfeathers.typepad.com
  14. Re: Languages are the culprit[ Go to top ]

    Maybe but the language of the code is only one part of any testing strategy. The language of the specification is probably the biggest problem since that is (generally) not so provable mathematically. The challenge is to both do things right and do the right thing. It seems that SOA should have its own testing strategy yet SOA (IMHO) makes things less testable than before due to its increasing tendency to favour dynamic routing and late binding. The software world, as ever is becoming ever more difficult and thus to prove ahead of time: SOA, AOP, Parallelism, Virtualization, Utility Computing, Rules Engines, etc... We don't want to be bound by our contracts - we want to change things on the fly! I would be interested in any thoughts on how the testing community (or should I call you the validating community - sounds wrong, almost medicinal) are addressing this burgeoning problem. ray