Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-576 Testsuite tasks (tracking)
  3. WFLY-596

TS: Pick the most acceptable test packages organization



    • Sub-task
    • Resolution: Done
    • Major
    • None
    • None
    • None
    • None


      1) Split classes to src/main and src/test ?
      This seems to be decided before - integration tests suite has all classes in src/test.

      (02:35:15) barreiro: When I start I done it that way so that it clear to me what was the test code, the test subject and the resources — I knew that probably I would have to change the location later.

      2) Low-level Test packages micro

      (02:37:51) barreiro: should I create one sub package for each test — like /web/xxxTestCase — or stick with the old schema of having web/tests and web/servlets, ... etc.
      (02:38:01) ozizka: Not sure if democracy is the principle to follow here, but I'd like devs to agree upon these things. TBD next week
      (02:38:41) ozizka: Depends if you reuse them.
      (02:39:24) ozizka: But generally, I'd prefer the first approach -
      (02:39:53) ozizka: with reused things being placed one level higher, or next to
      (02:40:16) ozizka: The structure should reflect test's structure
      (02:40:24) barreiro: IMO, democracy is not the way to go in a OSS project ... I'll do it the way you ask me to
      (02:40:34) ozizka: Ok
      (02:40:57) ozizka: But anyway - what's your preference?
      (02:41:07) ozizka: Or what would suite better for your case
      (02:42:42) barreiro: the ultimate goal is that someone from outside can easily understand what's going on. Like me, I just landed in this project.
      (02:43:58) barreiro: surely that it should reflect the test's structure. but I would rather have a common structure in most modules ...
      (02:45:30) barreiro: like, at some level there is a clear list of the tests in the package that is not mixed with other stuff — be it a list of packages or a test package with all the test classes
      (02:45:43) ozizka: Well, 1st option is current practice, I'd stick with that.
      (02:46:47) barreiro: and from there should be clear (as possible) what resources are used.
      (02:47:34) ozizka: I was thinking about using a mechanism used in Wicket framework, if you know that,
      (02:47:57) ozizka: which is, having a mechanism to load resources from places
      (02:48:04) barreiro: After a while I start to understand how AS6 is structured ... the problem is that there is too much voodoo in the back that defeats it's purpose.
      (02:48:18) ozizka: where the test class is loaded, or it's superclass, etc.
      (02:48:45) ozizka: Eventually it could go by packages up. But perhaps too magical for a testsuite
      (02:49:10) ozizka: Right. That's the voodoo.
      (02:56:27) barreiro: yep. Shrinkwrap and arquilling are great for that. The magic is greatly reduced, without adding much complexity.
      (02:58:10) ozizka: One other argument to have the package-per-test separation is that if we decided the other way, moving the files would be easier




            ozizka_jira Ondrej Zizka (Inactive)
            ozizka_jira Ondrej Zizka (Inactive)
            0 Vote for this issue
            0 Start watching this issue