- 浏览: 405361 次
- 性别:
- 来自: 上海
文章分类
- 全部博客 (255)
- Android (53)
- java (57)
- javascript (7)
- linux (19)
- springside3 (6)
- spring (2)
- struts2 (11)
- hibernate (2)
- jsp&servlet (15)
- jquery (1)
- ExtJs (5)
- freemarker (1)
- apache (5)
- mysql (3)
- tomcat (3)
- eclipse&maven (23)
- 电脑小技巧 (1)
- 配置安装 (3)
- 开源框架 (2)
- 设计模式 (2)
- 架构 (2)
- ajax (1)
- 正则表达式 (7)
- 测试 (2)
- 装修 (1)
- 不错的软件 (4)
- http协议 (2)
- 网络 (2)
- windows (2)
- nodejs (1)
最新评论
-
yhyx:
好
JAVA URI URL区别 -
dingbuoyi:
我文章很早以前写的啊 估计软件版本早更新了 你要自己研究一下
windows下Sublime Text 2开发 Nodejs -
di1984HIT:
写的很好,学习了
【转帖】IP网段的计算和划分 -
农民柏柏:
感谢分享
【转】Android实现人人网点击“+”弹出效果 -
lianwanf:
大神,求源码,很想要那jar包.官方的不懂下载啊.谢谢啊. ...
开源框架ignition[二]
原文http://googletesting.blogspot.jp/2010/12/test-sizes.html
by Simon Stewart
What do you call a test that tests your application through its UI? An end-to-end test? A functional test? A system test? A selenium test? I’ve heard all them, and more. I reckon you have too. Tests running against less of the stack? The same equally frustrating inconsistency. Just what, exactly, is an integration test? A unit test? How do we name these things?
Gah!
It can be hard to persuade your own team to settle on a shared understanding of what each name actually means. The challenge increases when you encounter people from another team or project who are using different terms than you. More (less?) amusingly, you and that other team may be using the same term for different test types. “Oh! That kind of integration test?” Two teams separated by a common jargon.
Double gah!
The problem with naming test types is that the names tend to rely on a shared understanding of what a particular phrase means. That leaves plenty of room for fuzzy definitions and confusion. There has to be a better way. Personally, I like what we do here at Google and I thought I’d share that with you.
Googlers like to make decisions based on data, rather than just relying on gut instinct or something that can’t be measured and assessed. Over time we’ve come to agree on a set of data-driven naming conventions for our tests. We call them “Small”, “Medium” and “Large” tests. They differ like so:
Feature Small Medium Large
Network access No localhost only Yes
Database No Yes Yes
File system access No Yes Yes
Use external systems No Discouraged Yes
Multiple threads No Yes Yes
Sleep statements No Yes Yes
System properties No Yes Yes
Time limit (seconds) 60 300 900+
Going into the pros and cons of each type of test is a whole other blog entry, but it should be obvious that each type of test fulfills a specific role. It should also be obvious that this doesn’t cover every possible type of test that might be run, but it certainly covers most of the major types that a project will run.
A Small test equates neatly to a unit test, a Large test to an end-to-end or system test and a Medium test to tests that ensure that two tiers in an application can communicate properly (often called an integration test).
The major advantage that these test definitions have is that it’s possible to get the tests to police these limits. For example, in Java it’s easy to install a security manager for use with a test suite (perhaps using @BeforeClass) that is configured for a particular test size and disallows certain activities. Because we use a simple Java annotation to indicate the size of the test (with no annotation meaning it’s a Small test as that’s the common case), it’s a breeze to collect all the tests of a particular size into a test suite.
We place other constraints, which are harder to define, around the tests. These include a requirement that tests can be run in any order (they frequently are!) which in turn means that tests need high isolation --- you can’t rely on some other test leaving data behind. That’s sometimes inconvenient, but it makes it significantly easier to run our tests in parallel. The end result: we can build test suites easily, and run them consistently and as as fast as possible.
Not “gah!” at all.
引用
by Simon Stewart
What do you call a test that tests your application through its UI? An end-to-end test? A functional test? A system test? A selenium test? I’ve heard all them, and more. I reckon you have too. Tests running against less of the stack? The same equally frustrating inconsistency. Just what, exactly, is an integration test? A unit test? How do we name these things?
Gah!
It can be hard to persuade your own team to settle on a shared understanding of what each name actually means. The challenge increases when you encounter people from another team or project who are using different terms than you. More (less?) amusingly, you and that other team may be using the same term for different test types. “Oh! That kind of integration test?” Two teams separated by a common jargon.
Double gah!
The problem with naming test types is that the names tend to rely on a shared understanding of what a particular phrase means. That leaves plenty of room for fuzzy definitions and confusion. There has to be a better way. Personally, I like what we do here at Google and I thought I’d share that with you.
Googlers like to make decisions based on data, rather than just relying on gut instinct or something that can’t be measured and assessed. Over time we’ve come to agree on a set of data-driven naming conventions for our tests. We call them “Small”, “Medium” and “Large” tests. They differ like so:
Feature Small Medium Large
Network access No localhost only Yes
Database No Yes Yes
File system access No Yes Yes
Use external systems No Discouraged Yes
Multiple threads No Yes Yes
Sleep statements No Yes Yes
System properties No Yes Yes
Time limit (seconds) 60 300 900+
Going into the pros and cons of each type of test is a whole other blog entry, but it should be obvious that each type of test fulfills a specific role. It should also be obvious that this doesn’t cover every possible type of test that might be run, but it certainly covers most of the major types that a project will run.
A Small test equates neatly to a unit test, a Large test to an end-to-end or system test and a Medium test to tests that ensure that two tiers in an application can communicate properly (often called an integration test).
The major advantage that these test definitions have is that it’s possible to get the tests to police these limits. For example, in Java it’s easy to install a security manager for use with a test suite (perhaps using @BeforeClass) that is configured for a particular test size and disallows certain activities. Because we use a simple Java annotation to indicate the size of the test (with no annotation meaning it’s a Small test as that’s the common case), it’s a breeze to collect all the tests of a particular size into a test suite.
We place other constraints, which are harder to define, around the tests. These include a requirement that tests can be run in any order (they frequently are!) which in turn means that tests need high isolation --- you can’t rely on some other test leaving data behind. That’s sometimes inconvenient, but it makes it significantly easier to run our tests in parallel. The end result: we can build test suites easily, and run them consistently and as as fast as possible.
Not “gah!” at all.
发表评论
-
listview 几个重要属性
2012-06-20 06:54 974参考资料 http://www.cnblogs ... -
android项目mvn开发
2012-06-19 07:12 884项目主页 http://code.google.com/p/m ... -
你真的会用AsyncTask吗
2012-06-24 19:24 1445一个典型的AsyncTask应用 public class ... -
关于AsyncTask的RejectedExecutionException异常
2012-06-24 19:24 3163当运行的AsyncTask 实例数量过多的时候会引发Rejec ... -
android.view.WindowManager$BadTokenException: Unable to add window -- token andr
2012-06-08 09:59 13036因为使用了AsyncTask 异步线程在线程完成以后的onPo ... -
ADT 17 导入JAR包
2012-06-07 17:48 1145引用 Eclipse ADT 17 以上版本用户,请在工程目录 ... -
android textview 自动链接网址 修改默认点击事件
2012-06-06 18:04 107371 修改XML文件即可,android:autoLink=&q ... -
【转】Android项目更换开发环境时出现的 java.lang.VerifyError 异常解决办法
2012-06-06 07:55 923引用 项目是从同事的电脑上直接拷贝过来的,项目里面的jar包是 ... -
android 判断Service是否开启
2012-05-31 10:12 3485被判断的Service 必须是带包名的全名 通过Servic ... -
android 写入收件箱
2012-05-21 10:58 823<uses-permission android: ... -
ndroid junit入门(四)Service测试
2012-05-18 11:26 772public class TestService exte ... -
android junit入门(三)Application测试
2012-05-18 10:54 1104测试Application public class T ... -
android junit入门(二)Activity测试
2012-05-18 10:38 2318测试ACTIVITY 直接上类了 public clas ... -
android junit入门(一) JUNIT测试
2012-05-18 09:54 1314新建ANDROID TEST项目 ECLIPSE右键--> ... -
imagebutton 带文字
2012-05-16 13:59 880<FrameLayout ... -
android orm
2012-05-10 17:58 970选择了http://ormlite.com/ 里面还支持AN ... -
android 隐藏虚拟按键
2012-05-09 16:14 11186一 全部隐藏 可以试下 <uses-sdk andro ... -
android 切图
2012-05-03 15:19 14161 程序launcher icons规格 3 ... -
新浪微博API杂记
2012-05-02 17:14 8751 获取指定用户的微博 https://api.weibo.c ... -
获取新浪微博的ACCESS_TOKEN
2012-05-02 16:00 57511 https://api.weibo.com/oauth2/ ...
相关推荐
Junit入门实验Junit入门实验Junit入门实验Junit入门实验Junit入门实验Junit入门实验Junit入门实验Junit入门实验Junit入门实验Junit入门实验Junit入门实验
在JUnit中使用@Rule测试文件和目录Java开发Java经验技巧共3页.pdf.zip
Android下使用JUnitTest用例,可以参见博客:http://www.cnblogs.com/plokmju/p/Android_JUnit.html
今天小编就为大家分享一篇关于Junit 5中@ParameterizedTest与@EnumSource结合使用,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
Debug as android Junit Test 4.Logcat就能看到测试输出 AndroidManifest.xml导入(已做好) 1. <!-- Android JUnit配置 --> <uses-library android:name="android.test.runner" /> 2. targetPackage与上面...
Junit是java中测试的必备工具,Junit_test这个程序是更好的实现对Junit的了解。帮助大家学习
今天小编就为大家分享一篇解决java junit单元测试@Test报错的问题,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
android junit 例子代码,自学小例子。如果不能下来可以直接联系我
在本文中,你将会学习到如何在Eclipse中创建Android JUnit的单元测试工程以及在不同的条件下创建及运行自动测试用例
我自己粗略的写了一下JUnit和android里面对JUnit的应用,因为没有太多时间整理,所以很粗略,等有时间再好好整理一下,见笑了。
Junit入门练习代码。
一个Gradle插件,允许在使用AndroidGradlePlugin3.2.0或更高版本的Android环境中执行JUnit5测试。
自动化单元测试可以做许多的事,并帮你节省时间。它也可以被用作快速检验新建工程或进行冒烟测试。始终,单元测试是作为...Android SDK支持JUnit的自动化单元测试。本教程假设你已熟悉Android和JUnit在Eclipse的使用。
android junit.rar android junit资料,讲解的很详细。
我以前写的一个junit入门的培训ppt,传了大家参考一下
JUnit入门,Junit入门学习,Junit初学者!
Android JUnit单元测试基本实例
很简单的说明,这是好的一个开始,希望大家能够看到,学习测试是很重要的。
android-junit5 一个Gradle插件,允许使用Android Gradle Plugin 3.5.0或更高版本在Android环境中执行测试。 如何? 该插件为项目的每个构建变体配置单元测试任务,以在JUnit Platform上运行。 此外,它附加到...
android-junit-report jar包及源码