junit gradle_eclipse run as gradle_idea junit测试

一个可编程的工具，能够以可执行和有序的任务来表达满足需要的自动化过程。

以Java为例，要得到一个简单可运行的Jar文件，需要下面几步：

1.编译源代码

2.运行测试（前提是你有测试） 3.拷贝Class文件到目标目录

4.打包Class文件为Jar文件

这是一个完整的可自动化的过程，在没有构建工具之前，是由谁来做？IDE。一个强大的IDE，以上的步骤都只需要按几个按钮，这让开发人员的生活变得很美好，完全集中在写出优秀的代码。

现在，本来整个开发过程只需要你一个人，随着任务的难度和复杂度的加剧，你的团队从一个人变成了3个人或者更多。这时，你肯定会需要代码集成，这个问题好解决，使用版本控制，无论是中心式的SVN还是分布式的Git，总之可以既可以解决版本问题，也解决代码集成的问题。

这种情况下，在没有自动化构建时，你肯定会遇到下面几个问题：

1.在我的机器上可以跑

2.从版本控制check out代码，发现编译不过，有人少提交了代码文件

3.有个人提交代码时没跑测试，导致其他人check out代码后，测试跑不过

4.版本发布时，由一个人来check out所有代码，在他自己的机器上编译打包，结果部署到服务器上运行不了

…

导致上面这些问题出现的原因都有两个特点：

1.手动介入

2.重复任务

开发人员要关注的应该是编写实现功能的代码，至于编译编译代码，拷贝文件，运行测试等一切重复和可自动化的事情都应该交给机器去做，因为人是容易犯错的。

在Java的世界里，目前在被使用的常用构建工具有三个：Ant，Maven，Gradle。

Ant的核心是由Java编写，采用XML作为构建脚本，这样就允许你在任何环境下，运行构建。Ant基于任务链思想，任务之间定义依赖，形成先后顺序。缺点是使用XML定义构建脚本，导致脚本臃肿，Ant自身没有为项目构建提供指导，导致每个build脚本都不一样，开发人员对于每个项目都需要去熟悉脚本内容，没有提供在Ant生态环境内的依赖管理工具。

Maven团队意识到Ant的缺陷，采用标准的项目布局，和统一的生命周期，采用约定由于配置的思想，减少构建脚本需要的编写内容，活跃的社区，可以方便找到合适的插件，强大的依赖管理工具。缺点是采用默认的结构和生命周期，太过限制，编写插件扩展麻烦，XML作为构建脚本。

如果有一个构建工具可以折中，同时拥有Ant和Maven的优点，是不是很爽？告诉你有，那就是Gradle。

基于Groovy的DSL，提供声明式的构建语言

采用标准的项目布局，但拥有完全的可配置性，就是可以改

通过插件，提供默认的构建生命周期，也可以自己定义任务，单独运行任务，定义任务间的依赖

强大的依赖管理工具，与Maven和Ivy仓库结合

与Ant天生兼容，有效的重用Ant的任务

多种实现插件的方式，强大的官方插件库

从构建级别，支持从Ant或者Maven的逐步迁移

通过包装器，无缝的在各个平台运行

看一个超级简单的例子：

如果你的项目采用标准的Maven布局（Java世界的标准布局）

在项目根目录下，创建一个build.gradle，这个是Gradle的构建脚本文件，就和build.xml，POM.xml道理一样。

那么你要实现Java的编译，测试，拷贝class到目标目录，打包Jar文件等，只需要在构建脚本中，使用下面一句话，使用Java插件。

然后运行gradle build。

没有介绍Gradle的基础知识，直接开始实战，目的是为了更快的让大家开始使用Gradle做构建，快速上手，当需要实现的自动化需求更复杂时，在深入学习基础知识。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-24737-1.html