How we can test daemons? about container-structure-test HOT 6 OPEN

Hey @dzavalkinolx, thanks for filing. As @zemanlx mentioned, I would say that what you're trying to do is more in the domain of integration rather than structure tests. However, I understand your use case and am currently trying to figure out how to support it.

I think the main issue here is I want the UX for more "integration" style tests to be more explicit, so I'm working out the best way to do that. I think for now I'll keep #43 in, and maybe work on supporting an option to specify an entrypoint for an image in the the yaml.

That said, I think I know why you're seeing the issue here. The Setup command runs commands and then commits their modified image to be the new base image for the test run, so things like running daemons get ignored. Having a specified entrypoint for the container should fix this.

from container-structure-test.

I know this is quite an old issue... but just wanted to share that we managed to do an "integration test" on a node server by doing the following, which I'd think would work for any daemon process:

commandTests:
  - name: 'server starts'
    command: 'bash'
    args:
      - '-c'
      - |
         /app/src/app > /home/node/output 2>&1 &
         sleep 1
         kill `pidof node`
         cat /home/node/output
    expectedOutput:
      - '.*Started server on port.*'

It works by:

1. Running the app as a daemon with the output piped to a local file.
2. Waiting enough time for the background app to run
3. Killing the app
4. Reading out the contents of the logfile to stdout

from container-structure-test.

After thinking about this issue again I believe you should revert #43. Basically, you change SUT when you override entrypoint - this is just conceptually wrong. Probably you can leave this option to override entrypoint but it should be opt-in, i.e. people can use it if their container are not testable otherwise but I think the general approach should be that people should change their container to make them testable. Like with unit testing for source code, instead of trying to mock dependency somewhere in private property of the class using reflection people should move dependency to the constructor.

from container-structure-test.

I think your case is close to #53 (comment) and you are trying to do integration and not structure test.

from container-structure-test.

@zemanlx Well, from classical point of view it is and integration test. However, if we think about container as a unit then it is more like a unit test. I want to call class method, class here is container and method is that responds on the exposed port.

But it doesn't matter in the end. We need some generic solution to test application installed inside container. Before I discovered this project I used https://github.com/sstephenson/bats but it requires me to build a test images based on SUT image with bats installed. Also, tests written in bash aren't that readable that's why I'm very happy with this new tool.

from container-structure-test.

I'm building an image for my project [blockchain2graph]https://github.com/straumat/blockchain2graph) and I need to start a neo4j server in my docker image. I would like to do a neo4j status to check if my deamon is running. From what I understand here, it seems your tool is not made for that ?
Is there a tool I should use to complete your tool or will you add this feature later ? Thanks

from container-structure-test.