Unit Testing in AQRIS

Input related to Unit Testing on different projects/experiences you have worked on is needed. I talked with some people here in the office and a pattern/common points of how usually our approach is done couldn't be found. Reasons for that are many:

  • it depends very much on type of code (core code, business logic code, JDBC code..)
  • requirements concerning to test are different on each project.
  • make effective unit test on legacy code is very difficult.
  • other complicated situation is when you don't have clear separation between code you have been developing and legacy code (as an definition of an interface between them or a even a module, for instance).

All of these reasons make your approach be different for each situation.

But still some patterns could be found, like on AMS Development, it is required to code coverage of new code should be at least 80% and it is not required to cover some kind of code, like getters and setters.

On other projects (specially external ones), a pattern/common points on Unit Testing that AQRIS developers always take care of, no matter if it is a client requirement, is not yet defined/mapped.

Please, share experience you have on different projects you have been working on in order to find some common tasks we usually do concerning unit testing.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (10)

 

  1. Feb 05, 2007

    Arseni Grigorjev says:

    There are lots of problems related to the topic. One of them, is the process of ...

    There are lots of problems related to the topic. One of them, is the process of testing HTTP controllers, which was covered in one of the Ürgo's posts here. So the possiblity to test code depends also on the design and overall application architecture.

    Also, not only getter and setter method tests are ambigious, but also tests for delegating methods, like:

    public SomeStuff getSomeStuff() {
	logger.debug("Will get some stuff!");
	return getDAO().getSomeStuff();
}

    Does it have much sense to test this method? I'm not sure about it.

    Also I find it problematic to test my current [JavaScript]/Ajax code (we use DWR-framework in our project). It combines both, un-testable [JavaScript] code, and delegating bean code (like the example above).

    1. Feb 05, 2007

      Risto Alas says:

      I usually don't write tests for delegating methods and getter/setter methods, bu...

      I usually don't write tests for delegating methods and getter/setter methods, but they get (indirect) coverage anyway.

      1. Feb 05, 2007

        Arseni Grigorjev says:

        If you mean, that you write tests for the code, which is invoked by the delegati...

        If you mean, that you write tests for the code, which is invoked by the delegating method (in given example, that would mean writing tests for the DAO code), then such 'indirect' coverage cannot be measured by automated tools. And aiming for some given % of coverage becomes more problematic.

        Which somehow brings me to an idea, that low % of test coverage, doesn't really mean, that you have a poorly tested code.

        1. Feb 05, 2007

          Risto Alas says:

          No, I mean tests for the code that invokes setters or getters (and delegators, e...

          No, I mean tests for the code that invokes setters or getters (and delegators, etc).

          If no code ever calls these getters and setters, then let's delete the getters and setters; otherwise, if there is some code that uses these getters and setters, then tests for that code will test the setters and getters as well.

          1. Feb 05, 2007

            Arseni Grigorjev says:

            OK, that's better, but covers only a part of possibilities. For example, curren...

            OK, that's better, but covers only a part of possibilities.

            For example, currently my AJAX calls are processed using following invocation path:

            JavaScript (AJAX)> Delegating Bean (working as a gateway to the core) --> Core Service --> DAO

            What the heck should I do?

            1. Feb 05, 2007

              Risto Alas says:

              Yes, of course we don't work with AJAX, and I don't know how to test it... I can...

              Yes, of course we don't work with AJAX, and I don't know how to test it... I can only guess that tools like Watir may help, and that most tests would have to run against mock server.

  2. Feb 05, 2007

    Risto Alas says:

    On new EGET casino projects, there is basically a requirement to have 70..80% JU...

    On new EGET casino projects, there is basically a requirement to have 70..80% JUnit coverage, at least for "core" code (meaning business logic and such; we don't write database code ourselves, but if we did, we'd have to test that too). The plan is to have such coverage for all projects in some 6 months or so.

    BTW, it's not always clear what that 80% means; I usually think that it means line coverage, because branch coverage is a more complicated subject. Different tools measure branch coverage differently (perhaps because they measure from .class files, not .java files, so things like compiler optimizations alter the code before measuring).

    But anyway, if you do Test-Driven Development, you get some 80% coverage automatically (no need to measure coverage then )

  3. Feb 06, 2007

    hugo.lousa says:

    My post wasn't intended to discuss the effectiveness of approach A or B, unit te...

    My post wasn't intended to discuss the effectiveness of approach A or B, unit test in type of code A or B, if your class has only delegating methods or has the real implementation of your method, or if 50-70-80-100% is the adequate coverage.

    I wanted to know if Aqris programmers care about unit testing when it is not a explicit requirement of client. If it is a common practice on our projects and we have the understanding of its importance.

    If your way approach is X or Y, that's another history!

    1. Feb 06, 2007

      Risto Alas says:

      I care about unit testing, even if clients hate it

      I care about unit testing, even if clients hate it

  4. Feb 07, 2007

    Ürgo Ringo says:

    I think also that unit testing is very beneficial. In addition I believe that ha...

    I think also that unit testing is very beneficial. In addition I believe that having some specific converage level is good practice that should be used even if customer doesn't directly require it. It should be agreed by all team members preferably in the beginning of the project. High coverage doesn't of course necessarily mean good design but it is one measureable attribute that makes it easier to evaluate your situation.

Add Comment