Is there some kind of tool for testing gradle scripts? Like JUnit is for testing Java code.
I would like to test my build.gradle script in way to see if it works properly, but would not like to do changes to the development repository (like commiting somethnig, adding test tags and so on).
Is there a way to do such thing, in lets call it, "transaction" manner, as if to do changes, see if it is doing as I intended and then rollback it.
Or do you recommend to mock my repository and all other needed data (something like staging only for my build script testing) and then do my things there?
What is the best practice for doing this?
Please take into consideration that I am gradle newbie. :)
Thanks in advance for any kind of advice/help.
mismas
There is no single purpose tool for this. OTOH there are various possibilities how to test your code. If your build logic is in buildSrc project - http://www.gradle.org/docs/current/userguide/organizing_build_logic.html#sec:build_sources - you can put your testing code there. Of course you have to decide how to test your code to avoid interaction like repository changes.
You can take a look at Gradle codebase. There are plenty of integration tests where you can find ideas. Aside from unittest it is likely you will want to use Gradle Tooling API to control build started from your tests.
More recent versions of Gradle ship with TestKit.
Related
I am looking into Espresso Framework to adopt the best practices for writing tests for a multi modular Android projects (MVI/MVVM).
Is it a good idea to cover/write all the Espresso tests inside the app module (or) it needs to be isolated specific to each modules?
Is there any other best practices for MVI/MVVM based Android projects? if so, please comment and provide references if any
Language used: Kotlin
I have recently been implementing espresso tests in the multi-modular project where I work. Through some research and help from senior developers, I think I will be able to guide you a bit in the proper direction.
For the first question, Yes, it's essential that all the tests related to a particular activity remain in their corresponding 'test' class. That keeps it modular and easy to debug. So, one should make a test class for a particular activity and that should be in the corresponding module that the 'activity' belongs.
All these test classes can then help you to build a 'TestSuite' which could be used to make a flow for testing the app's specific features. In a test suite, one needs to mention those classes that make that flow.
After all this research and as per knowledge, I guess, this approach is good enough for large projects as well since the app I am working on is really big.
Blocker :
In a multi-modular project, I am still not able to create the test suite since I am not able to import those test classes in the main app module. But this issue will be fixed very soon. I'll definitely update it here when I'll get the method to do so.
Please do comment, if I am doing something wrong. Suggestions are a warm welcome.
We are three testers and going to prepare automation project with selenium and java code so what are the steps for environment setup , scripts integration and running the testcases and getting the results for the whole project suits
So there are a few things we have to use in order to allow multiple engineers to work on the same framework.
Step 1) Creating the framework, assuming you know how to do this already, you have working tests you can skip this stage, however if not please follow the tutorial i link below.
http://toolsqa.com/selenium-webdriver/
Step 2) Creating a REPO, my preference is GitHub, you can use any git repo however i will post the guide to set one up with GitHub, its a similar process for all. This will allow you to merge code properly without causing conflicts.
https://help.github.com/articles/create-a-repo/
Step 3) Source Control program - to push, pull and fetch from your GitHub Repo, you can do this from Command Prompt however i find cloning the repo into a program like 'SourceTree' is really easy, so i've posted that below.
https://confluence.atlassian.com/get-started-with-sourcetree
If you follow these 3 guides, you will be able to have your automation test scripts on GitHub by the end of the day.
If you have any more questions please do not hesitate to ask.
All the best, Jack
The easiest and most logical way to do this would be to create one branch in your CVS (git or SVN, etc) and have each person setup the dev environment in the same way. Work exactly like developers and pull code before you check-in/commit (this will ensure that one small error does not break your framework) and swear to resolve conflicts during merge (to ensure you don't step on each others' toes).
Also, before you kick off, agree on a standard of coding (including package naming, design pattern usage, filename and methodname usage) and if this is in sync with the dev coding standards in your company, even better.
There will be a few hiccups along the way, but experience is the best way to create a process for your development and check-in practices.
Good luck with your new project and happy coding!
You have asked two questions, in my opinion the answer of your questions is.
how multiple automation testers work in same selenium project - You can use any version control system, Git Hub is the best option which gives you a lot of facilities. You all three can work on same project at same time or you can go for any centralized version control system like tortoise svn which is not much likely used now a days. I will suggest Git Hub for that.
what are the steps for environment setup , scripts integration and running the test cases and getting the results for the whole project suits - It depends on various factors like application and the kind of framework you want to use, there are many frameworks which are widely used for automation testing like Modular Framework, Data Driven, Keyword Driven, BDD, Cucumber, TestNg etc or if you have bandwidth and time you can design your custom framework as per the needs.
I hope I put some glimpse on your queries.
Thanks
I am doing an assignment (implementing an algorithm), and I wanted to try, this time, implementing tests first. However, I simply do not know where to put them! Do I need to create a new project?
All the tutorials I have found mentioned what to write, but not the general method of proceeding when building a test suite.
I expected Monodevelop to have some kind of predefined structure (like a big "add test suite" button), but I could not find anything for FSharp.
Monodevelop seems to have many tools to deal with tests in a clean and principled way (it does have a big "run tests" button), therefore I thought I would structure my project so that Monodevelop "sees" my tests, so that I could use the tools from the graphical interface. It seems the most common way to write tests is to use NUnit, what if I use something else, like FsCheck?
I have stumbled upon a Github project called FSharpKoans, it seems to suggest that I should create a project called "MySolution.Test" inside a solution, is this the standard way?
What should be the type of the project then, is it a separate console application?
Thanks.
Yes, creating a separate "X.Test" project is the standard way of adding tests in .NET, F# is no exception here.
For testing framework, pick one that Monodevelop supports well if what you're looking for is IDE integration - NUnit sounds like a safe choice. You could conceivably use any framework in F# tests, so I would think what Monodevelop supports should dictate your choice here.
FsCheck is not a testing framework, it's a library for property-based testing that can be used in conjunction with any testing framework. You might want to look into it as it advocates a particularly interesting approach to testing, but it's by no means the only way or the required way of doing testing in F#.
I think the best practice would be to maintain the test suite in the same repo as the source code to keep the tests in sync with the code changes. But what if the infrastructure or the coding policy doesn't allow adding irrelevant files to source code? Is there a better way to keep sync between both code and tests by having a separate repo for testsuite? Thanks in advance
I think it depends on your goal/team and project. I have worked in both of the models and I found advantages and disadvantages of working with both.
Automation in the same repository:
Advantages:
You can share the code and element locators(for example with Espresso), so it is easy to maintain
It is easy for the developers to help with the maintenance (in case they want/have to)
It is more visible for developers to do the code review and check the PRs
Shared knowlodged about the code and tests between Devs and QAs
Devs can accidentally break automation code (but if qas are doing reviews this should be rare)
Test automation will have the same language as the development code
Disadvantages:
You can share code, so if you have a function with a bug and you are using the same function on your tests, your tests are going to have a bug as well
QAs can accidentally break development code (but if devs are doing reviews this should be rare)
E2E tests between projects will not make sense since the tests are placed in a repo of one project and having integration with others
E2E tests between projects will need to have mocks to test scenarios on the other products/projects otherwise, as said above, it won't make sense to have the test project in a project repo
Can't share code/functions between projects as it will be confusing to have a test project sharing functions with other test projects in different repos (Unless you create a test repo with these shared functions) + you may have a test automation coded in javascript for the web project and for the mobile project you are going to have the same code as the development team, which could be different from the web, like kotlin or swift
Automation in separated repository:
Advantages:
You can share the code between test projects
You will reduce the maintenance cost as the project can be shared between different platform projects
Test automation can have the language that is more known for the team who is going to code or the language which has more advantages when maintaining the code between projects in different platforms
Disadvantages:
Not really visible for the developers as they might not follow
You can proper create an E2E tests involving all the projects in different platforms without mocking them
It is not a big motivation for the developers to follow and maintain the test automation
Anyway, I may be missing something, but I just tried to remember all the key points. In the end the team should decide this together as this again depends if the developers are going to maintain the tests as well and if you are going to perform e2e tests with or without the need of mocking the other projects
In my current Test project, we are using TestNG as a testing framework. We have the Test suites in a separate folder structure, but still they are part of the project.
what if the infrastructure or the coding policy doesn't allow adding irrelevant files to source code
Also are organized in test_suite.xml files (represented by one XML file, as suite is the feature of execution) for different scenarios, since by default they cannot be defined in the testing source code.
The main advantage of this is the flexible configuration of the tests to be run. Also they can be supported by a tester with very little domain knowledge of the Test project.
I'm well into learning Scala now and enjoying it very much; I hope to start future projects in it, rather than Java. What I'm enjoying less is the (relatively) poor IDE support. I've found both IDEA and Eclipse with the Scala Plugin (including nightly builds) to be a bit unreliable or difficult to use - I want something I can always depend on. E.g. yesterday I couldn't get a fresh install of eclipse+plugin to run my tests at all, or even open an editor window!
I'm considering hopping between Eclipse/IDEA depending on which suits the task at hand best and more importantly cutting my dependence on the IDE for building and running tests (ScalaTest). This is non-trivial for me since I've grown up on Java in Eclipse; leaving Eclipse SVN to use GIT was initially a big deal. Given that I only have time to learn one tool, should it be Ant, Maven, buildr, sbt,.... ? How do other people work?
I have used both Maven and sbt with Scala and found both of them pretty easy to use.
However, sbt feel much more closer to Scala as its build files are written in Scala itself (as opposed to XML in Maven) and sbt feature a build REPL, has continuous compilation and testing etc.
So I would advise you to use sbt for a simple Scala project.
But in case you want to create standard Java projects like WAR, EJB etc, I feel like Maven has a better support for them.
Also Maven has an enormous plugin ecosystem which enables you to do virtually everything, code coverage, reporting, code standard checking, documentation generation, and a lot more.
I'd use SBT with IDEA. Though I haven't tried it, I know there's some support for integration of SBT and IDEA.
Anyway, SBT is a great basis for all Scala building&testing needs.
EDIT: Uuuups. Sorry. Actually I misread your question and only commented on IDEs. When it comes to building the project I use make ;) because it is well integrated into Vim
while I wouldn't want to do ANY Java Project without IDE, I'm currently doing a fairly large project just in Vim. I know that's a quite a "stone-age approach" but it works just fine.
On one hand I was fed up by the buggy/slow/lacking Scala support of all IDEs. I tried Scala, netbeans and IDEA and found working with them (in Scala) rather painful.
On the other hand Scala has some properties that help when working with a simple Editor: you can have more classes in one file so I usually define a whole package in one file which again doesn't grow too large, since Scala class are usually very (or even extremely) small. So I usually have only two or three files open at a time and hence don't need a package/file management.
I couldn't get code folding by languages tags to work but folding by indentation works just fine if you stick to Scala's indentation conventions.
One thing that doesn't work is auto-completion. But then again, this makes me write more loosely coupled objects ;)
Buildr supports Scala and Java as first class languages, with support for ScalaCheck and ScalaSpecs, and of course also has enough plugins to make it a good contender for Maven.
Just adding my two cents. I think you should give Netbeans a try too. Its supposed to be the most Scala-friendly among the three major players (Eclipse, Idea and Netbeans).
I have been having a lot of fun with Netbeans 6.8 and scala-2.8.0.r22602-b20100720020114
It is fair to say that I wouldn't be programming Scala now if it hadn't been for the Netbeans plugin. I have spent a fair bit of time trying to get it to work as smoothly with the others, but without much success.
I use Netbeans for developing and Ant for standalone build. Info on configuring Ant for Scala here:
http://scriptlandia.blogspot.com/2007/04/how-to-compile-and-run-scala-program.html