I think I am not the only one who is gonna ask this question next time.
After some experience with RoR I am impressed with the power of dynamic languages. Lots of projects are still forced for different reasons to use a java technology stack though. Since testing is an important part of any project I would like to hear your experience about building an enterprise project with groovy as main testing language and NOT in production code. It think this is a perfect scenario to start with this language.
How was your experience for this constellation, specially regarding following points:
Integration in Eclipse: calling java apis, still with auto complete functions possible?
Stability any Performance of groovy, if you have a typical java stack (Spring, OR-Mapper)
Integration of the groovy tests in the ant build and continuous integration server
Adaptability by a java team of 4 developers
Thanks a lot!
Denis.
Integration in Eclipse: minimal, but effort is underway by SpringSource, with expected good results in a couple of months;
Groovy is stable in my opinion, but the performance is not stellar. But then again unit testing does not need to be ultra-fast, just fast;
Integration: it's done for both maven and ant;
Integration into Eclipse is functional. It is not the best but it is continually improving. It is certainly good enough for unit tests.
Stability is fine. Built on the JVM I have not had any stability issues with Groovy. As for performance it is a bit slower than pure Java but you can mix Java code in if that is a huge problem. Honestly, I don't think performance should be a concern for a testing language. Groovy performance is good enough for most applications.
Integration into unit tests is pretty easy. Groovy compiles to Java classes. As long as your groovy libraries are on the classpath, JUnit can execute your groovy tests. I use groovy for automated tests mixed in with some older Java only unit tests. We run it nightly in CruiseControl in a Maven project.
Groovy is pretty easy to learn. It is similar enough to Java that your 4 developers who probably know Java should have no trouble picking it up.
Related
I have some programming experience and want to switch to QA roles that suit my skills better, I have more knowledge of Java but some Python.
I am wondering if I should focus on Selenium that I have some knowledge of or Protractor or Cypress that are considered as the latest standards?
I am more of a front end guy as a developer.
Also, I generally use guru99, tutorialspoint or w3schools to get started. Any other great resources for free or less expensive for quick learning for these topics?
Will cloud upgrades affect this learning process?
Please advice.
Selenium is still the most wide used web UI automation tool, having a lot of tutorials for any level of experience etc. Also, once you know one tool, you will be able to learn other similar tools in the future easily. Also, Selenium supports and mainly used in programming languages you already know while the other tools you mentioned using JavaScript. So, I'd advice you to start (and then continue) with Selenium.
I think Protractor is being dropped by Angular in favor of Cypress.
Please see
The State of end-to-end testing with Angular
...we’ve decided to deprecate Protractor
and #cypress/schematic.
Component testing
Also consider that Cypress has first-class component testing (as well as e2e testing) which has better speed than e2e but better coverage than unit testing.
See Quickstart Angular
and Cypress Component Testing vs Angular Test Harness
Is there a way to integration test my JUnit Jupiter extension? Of course I can test a good cases of extension usage, but I would like to test things like:
Does it fail tests as expected?
Are the correct reports written on test end?
Is there some built in support for this?
There is no explicit Jupiter extension testing framework -- but with version 1.4 there'll be the Platform Test Kit that you may use to execute the Jupiter engine and your extension in one-go and assert the outcome of a test run.
For details see: https://junit.org/junit5/docs/snapshot/user-guide/#testkit and in addition to that documentation, find usages of the Platform Test Kit within the "platform-tests" project of JUnit 5. For example at: https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/java/org/junit/platform/testkit/engine/ExecutionsIntegrationTests.java
You should not perform integration testing for your own extension of Junit. The Junit 5 API is very, very stable and I bet that your extension will work the same for the entire life of Junit 5. Integration testing is useful in a constantly evolving environment, but Junit only ever adds features and never changes them (unless there is a bug).
If you perform integration testing for your own Junit extension, it's like you're testing Junit itself. Why would you test Junit instead of your extension? Let Junit be tested by Junit developers, unless you think you found a bug. But testing Junit for the sake of testing Junit is a waste of your own time, even if unconsciously you think you're only testing your own extension.
So that kind of tests should be done on the long term by getting your users to report issues to you: "Hey, AwesomeExtension works with Junit 5.A.B but not with 5.X.Y", then find out why they say that and if the issue is not with your extension, then report with Junit.
However, make sure that you get your extension... unit-tested.
I am currently investigating how best to test our OSGi application intended to run on Apache Karaf. The obvious option is Pax Exam with labs-paxexam-karaf (see http://iocanel.blogspot.com/2012/01/advanced-integration-testing-with-pax.html for a tutorial). However, I am concerned about performance (since Pax Exam apparently starts a new framework for every test method). I've also found that Arquillian has some OSGi support, though that isn't its main focus. JUnit4osgi isn't an option, as it only supports JUnit 3.
For someone unfamiliar with either framework, which is better to start with? What are the tradeoffs?
Why use Arquillian if you're after proper OSGi support? =)
When looking at PaxExam make sure the docs refer to PaxExam 2 - there are substantial differences between v 1 and 2.
PaxExam will take a while to get to grips with, but you'll learn heaps about OSGi in the process (definitely a good thing, but can still hurt).
In parallel to #Dmytro's answer, the Test Containers include a Native container which is run with the same VM as the junit test - meaning you can launch with debug in Eclipse. This works especially well with the org.eclipse.m2e:lifecycle-mapping maven eclipse plugin and the org.ops4j.pax.exam:maven-paxexam-plugin. This method is fantastic, complete IDE integration.
PaxExam documentation is a bit sparse, but there are some good examples (see the Native launcher with main method that provides interactive shell) and wiki doc. If you get stuck the mailing list people (general#lists.ops4j.org) are very helpful.
Another alternative is to look at Karaf's paxexam, very slick and easy to get a Karaf instance up and running (features.xml etc).
Personally, I just use PaxExam2 as I'd prefer to have no explicit dependencies on the framework provider (nothing against Karaf at all, it rocks).
Based on Reactor Strategies Pax-Exam can run all test methods in the same OSGi container.
The EagerSingleStagedReactorFactory of Pax Exam 2.x (aliased to PerClass in Pax 3.0) lets you run all test methods of a given class in the same OSGi container.
With the PerSuite strategy introduced in Pax Exam 3.0.0.M1, all test classes of your suite run in the same container.
By the way, Pax Exam 3.0 supports Java EE and CDI containers in addition to OSGi, so there is even more functional similarity with Arquillian, only Pax Exam is coming from the opposite end.
With Pax Exam, there is no need to assemble deployments in ShrinkWrap style, they are built automatically from the classpath. Moreover, you can run suites of test classes with a shared configuration.
I know they both are for testing but I did not find much information about PhpRack here. Can we use them together in a project? Or only one can serve the purpose?
PHPUnit is a unit testing framework. Unit testing considers the testing of software from the perspective of discreet units of code, such as a class or method.
PHPRack is an integration testing framework. Integration testing considers the testing of how separate software modules/systems integrate together in a production environment.
Unit testing and integration testing are not the same thing. A development environment can use both.
I have been trying my hands on opensource tool JUnit for testing Java Code (Read it as from Whitebox testing Perspective), I want to start learning from scratch. Any suggestions on good books , pdf or links to tutorials woulld be appreciated
Thanks
Two books and a web site that I found useful:
Agile Java, Crafting Code with Test-Driven Development, Jeff Langr, 2005, Prentice-Hall.
Listing at isbn.nu
An older book that uses JUnit 3.8.1.
Excellent approach to learn Java, OO design, and TDD. Good code samples, explanations, and exercises. See the author's site for more data. He might also be found on the JavaRanch web site,
javaranch.com,
where more JUnit data can be found.
Test Driven, Practical TDD and Acceptance TDD for Java Developers, Lasse Koskela, 2008, Manning.
Listing at isbn.nu
See Appx A (Brief JUnit 4 tutorial in 2 pages of annotated code),
and Appx B (Brief JUnit 3.8 tutorial in 2 pages of annotated code)
if you need to translate between the two, eg, if your IDE supports only the older s/w.
I wanted to see both JUnit 3 and 4, and built a VM running Debian's unstable release. This gave me a more recent version of the Eclipse IDE that supported JUnit 4.