On Tue, 2008-08-12 at 11:29 -0700, Cédric Beust ♔ wrote:
> Hi,
>
> The .zip you can download from testng.org contains a jar file that
> will work on Windows, Linux and Mac OS (and a bunch of other minor
> operating systems).
If it s a great shame that TestNG appears not to have made it into then
Debian or Ubuntu repositories. Is there no-one willing to package it?
JUnit wins hands down on this, which means JUnit will be chosen over
TestNG for all the wrong reasons.
> --
> Cédric
>
> On Tue, Aug 12, 2008 at 11:01 AM, Hot_Phoenix <davi...@yahoo.com>
> wrote:
>
> Hello TestNG community,
>
> Can anybody tell me where to find a Linux version for TestNG?
> I surfed
> testng.org but did not get related information.
>
> Are the versions on http://testng.org/doc/download.html also
> for
> Linux? Or are they just for Windows?
>
> Thanks for all replies.
>
--
Russel.
====================================================
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077
On Wed, 2008-08-13 at 08:50 -0700, Cédric Beust ♔ wrote:
> Agreed, I think there is more harm done to TestNG's adoption from the
> fact that it's not part of Eclipse or Maven 2 (hopefully this part is
> fixed :-)) than because it's not shipped with Linux.
I think NetBeans and IntelliJ IDEA integration are as important as
Eclipse and Maven integration -- Maven means Maven 2 by definition :-)
I agree integration with the IDEs is a primary factor and that packaging
for Linux, Solaris, Mac OS X, Cygwin, etc. separately from the IDEs is a
secondary issue in comparison. There are however people who work
without using IDEs and for these people installation is a fundamental
concern, particularly where there are 30-50 or more machines to set up.
> --
> Cédric
>
>
> On Wed, Aug 13, 2008 at 8:32 AM, Cosmin Marginean
> <cosm...@gmail.com> wrote:
>
> Ok. Choosing JUnit for such reasons doesn't make sens to me at
> all. If
> there are people that prefer to use some completely different
> tool or
> technology JUST because they can get it through apt-get or yum
> or etc,
> then probably choosing a Java testing automation framework is
> not
> their biggest problem. Are we talking about actual developers
> here?
>
> Regards,
> Cosmin
Actually it is more likely a Sys Admin issue rather than a programmer
issue. For large projects infrastructure is how easy is it to install.
If everyone uses a copy of a preinstalled IDE and the IDE is used then
the whole Linux, Solaris, Mac OS X problem doesn't exist.
Having said this I still think TestNG should be packaged for Debian,
Ubuntu, Fedora, etc. if only as a matter of marketing and completeness.
Ubiquity, simplicity and ease of accessibility is the issue.
I am biased of course, I don't use IDEs.
Cédric, Cosmin,
I think NetBeans and IntelliJ IDEA integration are as important as
On Wed, 2008-08-13 at 08:50 -0700, Cédric Beust ♔ wrote:
> Agreed, I think there is more harm done to TestNG's adoption from the
> fact that it's not part of Eclipse or Maven 2 (hopefully this part is
> fixed :-)) than because it's not shipped with Linux.
Eclipse and Maven integration -- Maven means Maven 2 by definition :-)
>
> FYI, TestNG is already shipped with IDEA.
Only "sort of": yes there is support for the TestNG jar file being
available but there seems to be no way to run a TestNG test from the GUI
without invoking Ant or Maven. If you try to run a test suite as is
done in Eclipse then IntelliJ IDEA just tells you there are no JUnit
tests to be run for a TestNG-based test suite.
I am used to clicking on the package or the whole test package set and
saying "run the tests" and it is this that is not working. I have to
admit I still hadn't tried individual test cases.
> The other week I recorded a quick screencast for you showing just
> this:
>
> http://screencast.com/t/lHNHIyYQ2ey
>
> If you're still unable to view this, I'll re-record it using
> quicktime, mp4, or something else.
As soon as the play button is pressed, blackness descends. I am using
Epiphany on Ubuntu with the Adobe flash player (9.0 r124) installed.
The Totem plugins should be able to handle anything standard.
> I think the other problem you were having was rooted opening your
> project from a maven pom. Is the problem only apparant in projects
> opened from pom.xml's or from normal projects?
I thought I had ditched that version of the project (the one build as a
Maven import) and built one from scratch. Having done this of course
it seems easy to set up an associated Ant build but nigh on impossible
to create an associated Maven build. However, I have just spotted that
I can still do the Maven build so maybe I did not start again. I will
save the current IntelliJ IDEA control files and have another go.
Thanks.
As someone who does release their software stack as RPMs, I agree they
have a good benefit for projects that want to push out the binaries
into production systems, or other projects that redist their own stuff
in the format. Its not so important for developers, unless you've
embraced full locked down workstations and the dev teams arent
actually allowed near an IDE
But
-its a lot of effort to get good RPMs out
-you need to include a test strategy that tests installing, upgrading
and uninstalling. We use VMware images for this, with different
distros (RHEL, Fedora and Suse) to check that things work. Upgrading
is actually the hardest; the upgrade scripts are run before the old
version is uninstalled.
-the only 'standard' for managing java packages on linux, jpackage,
is very RedHat centric, and doesnt always apply to other systems.
I dont see eye-to-eye with the JPackage team, they cite some of my
viewpoints on packaging as fundamentally mistaken
https://www.zarb.org/pipermail/jpackage-discuss/2007-January/010956.html
https://www.zarb.org/pipermail/jpackage-discuss/2007-January/010989.html
https://www.zarb.org/pipermail/jpackage-discuss/2007-January/010999.html
-the JPackage world view is one version of an artifact per machine.
That is, one version of log4j only, one of servletapi, and not 'your
app has the specific set of jars your deploy team chose, alongside any
other jars that different apps have. Me, I think the ops team should
be in charge, not whoever provides your distro.
so, if you want to do an RPM or a .deb:
* have a real reason other than "it would be nice"
* have a use case (push testng out to 150 production servers)
* add upgrade and rollback as use cases
* drive the packaging from that
* make sure you understand how RPM/deb works, how the repositories and
their security and dependency models work
* come up with tests that work on virtual machines of some kind or
other; Xen, VMware or Amazon EC2 can all host appropriate images;
Centos can be used instead of RHEL 5.
I'm not going to offer to do this for anyone, though if someone were
to write and donate the smartfrog components to run testng tests, then
I could patch it in to our release process as one more RPM for me to
build, and one more RPM to test.
-steve