Make(file) juju tests and unit test easier to discover?

[David Cheney]

make it a hook means "make it an executable file, probably in the
hooks directory", that (maybe) calls make -C $CHARM_DIR test

On Sun, Nov 10, 2013 at 12:55 AM, Marco Ceppi <marco.ceppi at canonical.com> wrote:
> Could you elaborate on what you mean by "make it a hook"? I'm not sure how a
> hook fits the requirements of a test. It's not an event that fires by Juju
> and is run locally, outside of a deployment, all together.
>
> Thanks,
> Marco Ceppi
>
>
> On Sat, Nov 9, 2013 at 6:15 AM, Juan Negron <juan.negron at canonical.com>
> wrote:
>>
>> +1 on making it a hook.  It sounds like a good the juju way of doing it :)
>>
>>
>> On Sat, Nov 9, 2013 at 8:59 AM, David Cheney <david.cheney at canonical.com>
>> wrote:
>>>
>>> Lets make it a hook, that sounds like the only way it can be
>>> implemented without showing a bias towards any one solution.
>>>
>>> On Sat, Nov 9, 2013 at 10:26 AM, Marco Ceppi <marco.ceppi at canonical.com>
>>> wrote:
>>> > Hi all,
>>> >
>>> > I've been toying with this idea for the past few days after seeing a
>>> > Makefile in a charm. As we move closer to starting the audit on the
>>> > charms
>>> > in the charm store I'm trying to figure out best practices for the
>>> > juju-test
>>> > plugin to be able to run not only the integration tests but also unit
>>> > tests
>>> > that are starting to appear in more and more charms (LOVE THIS!)
>>> >
>>> > Originally, I figured unit tests would be included as a test file in
>>> > the
>>> > tests directory, eg:
>>> >
>>> > ```tests/01-unit-test
>>> > #!/bin/bash
>>> > set -eux
>>> >
>>> > sudo apt-get install python-nose
>>> >
>>> > CHARM_DIR=$(pwd) PYTHONPATH=$(pwd)/hooks nosetests -s
>>> > $(pwd)/hooks/tests
>>> > ```
>>> >
>>> > That way you could run the entire test suite, via `juju test`, or just
>>> > the
>>> > unit test with `juju test 01-unit-test`. However, I've noticed a lot
>>> > more
>>> > charms with Makefiles. I'd like to know if maybe utilizing existing
>>> > conventions would be better. In this case `make test` would preform
>>> > Unit
>>> > Tests, if any, and `make functional` could run the juju-test functional
>>> > tests.
>>> >
>>> > Thoughts on this? What should we recommend as a best practice - or even
>>> > a
>>> > policy? At the end of the day we'll need to know in order to make sure
>>> > the
>>> > charm testing infrastructure knows what to utilize.
>>> >
>>> > Thanks,
>>> > Marco Ceppi
>>> >
>>> > --
>>> > Juju mailing list
>>> > Juju at lists.ubuntu.com
>>> > Modify settings or unsubscribe at:
>>> > https://lists.ubuntu.com/mailman/listinfo/juju
>>> >
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>>
>>
>> --
>> Thanks,
>>
>> Juan L. Negron <juan.negron at canonical.com>
>> Mobile: +1 408 634 0292
>> Cloud Architect
>> Canonical Technical Services
>> Canonical USA
>> GPG : 0A62 BC70 5CBC B4DD F3E6  8A27 A6B1 F3F0 E6B5 F5A3
>
>