首页 > 代码库 > task19-21
task19-21
- 【说明】理想是丰满的，现实很骨感，昨天还说今天有望干掉5个小任务，看来是没可能了，兜兜转转地做了一天也才完成下面的这些
一：今日完成
- 19.学习Spring，配置Spring和Junit
1）先安装一下m2eclipse插件
创建了一个maven项目
导入现有项目
又发现昨天的本地配置似乎出了一些问题
配置优先级从高到低：pom.xml--->profiles.xml--->user settings --->global settings
打开maven仓库
貌似又碰到其它问题了，比如之前设置好的环境变量又找不到了，只能再改一下。
结果又碰到了eclipse配置问题
在stackoverflow有一个相关的答案，然后搞定了
2）好了，接下来开始spring和junit的学习之旅吧
先来说一下spring的基本概念
Spring是一个轻量级的IOC和AOP容器框架：
a,轻量级：程序实现不是很复杂，代码不是很多，占用资源不是很多，没有侵入性；
b，IOC（Inversion of Control 控制反转）：对象创建责任的反转（重点，核心）；
c, Aop(Aspect Oriented Programming):一种面向横切面编程的思想方式，可以进行功能性扩展，看前边的一篇转载的博客：面向横切面（AOP）编程
d，容器：可以容纳对象，并且可以控制对象的生命周期；
在eclipse里面用maven构建了一个ssh框架，构建中，，，，
构建完成后发现依赖包真的不用自己下载了!!!!
再加上配置文件，简直高大上啊
接下来看看junit的功能，我之前也只是知道它是单元测试，但是看了一篇文章之后发现，spring也有junit测试，怎么说呢，看下面的spring的框架组成
其实上面还应该有一个模块，单元测试框架
我们先来讨论下，在基于Spring的javaweb项目中使用Junit直接进行单元测试有什么不足
1）导致多次Spring容器初始化问题
根据JUnit测试方法的调用流程，每执行一个测试方法都会创建一个测试用例的实例并调用setUp()方法。由于一般情况下，我们在setUp()方法中初始化Spring容器，这意味着如果测试用例有多少个测试方法，Spring容器就会被重复初始化多次。虽然初始化Spring容器的速度并不会太慢，但由于可能会在Spring容器初始化时执行加载Hibernate映射文件等耗时的操作，如果每执行一个测试方法都必须重复初始化Spring容器，则对测试性能的影响是不容忽视的；
/////////使用Spring测试套件，Spring容器只会初始化一次！
2）需要使用硬编码方式手工获取Bean
在测试用例类中我们需要通过ctx.getBean()方法从Spirng容器中获取需要测试的目标Bean，并且还要进行强制类型转换的造型操作。这种乏味的操作迷漫在测试用例的代码中，让人觉得烦琐不堪；
////////使用Spring测试套件，测试用例类中的属性会被自动填充Spring容器的对应Bean
，无须在手工设置Bean！
3）数据库现场容易遭受破坏
测试方法对数据库的更改操作会持久化到数据库中。虽然是针对开发数据库进行操作，但如果数据操作的影响是持久的，可能会影响到后面的测试行为。举个例子，用户在测试方法中插入一条ID为1的User记录，第一次运行不会有问题，第二次运行时，就会因为主键冲突而导致测试用例失败。所以应该既能够完成功能逻辑检查，又能够在测试完成后恢复现场，不会留下“后遗症”；
////////使用Spring测试套件，Spring会在你验证后，自动回滚对数据库的操作，保证数据库的现场不被破坏，因此重复测试不会发生问题！
4）不方便对数据操作正确性进行检查
假如我们向登录日志表插入了一条成功登录日志，可是我们却没有对t_login_log表中是否确实添加了一条记录进行检查。一般情况下，我们可能是打开数据库，肉眼观察是否插入了相应的记录，但这严重违背了自动测试的原则。试想在测试包括成千上万个数据操作行为的程序时，如何用肉眼进行检查？
////////只要你继承Spring的测试套件的用例类，你就可以通过jdbcTemplate在同一事务中访问数据库，查询数据的变化，验证操作的正确性！
所以，我的目的很明显，结合着spring的测试套件来进行单元测试，在次之前，先来了解一下单元测试junit4
20.编写单元测试的代码，注意，你也可以尝试一下，先写单元测试的代码，再写接口，再写实现类。
1）JUnit4是JUnit框架有史以来的最大改进，其主要目标便是利用Java5的Annotation特性简化测试用例的编写。
先简单解释一下什么是Annotation，这个单词一般是翻译成元数据。元数据是什么？元数据就是描述数据的数据。也就是说，这个东西在Java里面可以用来和public、static等关键字一样来修饰类名、方法名、变量名。修饰的作用描述这个数据是做什么用的，差不多和public描述这个数据是公有的一样。
那为什么要进行单元测试呢？
我们在编写大型程序的时候，需要写成千上万个方法或函数，这些函数的功能可能很强大，但我们在程序中只用到该函数的一小部分功能，并且经过调试可以确定，这一小部分功能是正确的。但是，我们同时应该确保每一个函数都完全正确，因为如果我们今后如果对程序进行扩展，用到了某个函数的其他功能，而这个功能有bug的话，那绝对是一件非常郁闷的事情。所以说，每编写完一个函数之后，都应该对这个函数的方方面面进行测试，这样的测试我们称之为单元测试。
传统的编程方式，进行单元测试是一件很麻烦的事情，你要重新写另外一个程序，在该程序中调用你需要测试的方法，并且仔细观察运行结果，看看是否有错。正因为如此麻烦，所以程序员们编写单元测试的热情不是很高。于是有一个牛人推出了单元测试包，大大简化了进行单元测试所要做的工作，这就是JUnit4。
2）为了更清楚的了解测试流程，我先做一个简单的加减乘除测试来验证一下流程：
这是创建的项目，导入junit类库，生成calculate类的测试类
run as junit test ，测试之后，发现，一个错误，一个略过，两个成功
3）看一下测试类：
package com.ljl.junit4Test;
import static org.junit.Assert.*;
import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.*;
import org.junit.Before;
import org.junit.Ignore;
import org.junit.Test;
public class CalculatorTest {
private static Calculator calculator = new Calculator();
@Before
public void setUp() throws Exception {
calculator.clear();
}
@Test
public void testAdd() {
calculator.add(2);
calculator.add(3);
assertEquals(5, calculator.getResult());
}
@Test
public void testSubstract() {
calculator.add(10);
calculator.substract(2);
assertEquals(8, calculator.getResult());
}
@Ignore("Multiply() Not yet implemented")
@Test
public void testMultiply() {
}
@Test
public void testDivide() {
calculator.add(8);
calculator.divide(2);
assertEquals(4, calculator.getResult());
}
}
4）重点剖析一下（提到下面的知识点要能想到对应的例子）：
一、包含必要地Package
二、测试类的声明
三、创建一个待测试的对象。
四、测试方法的声明
五、编写一个简单的测试方法。
六、忽略测试某些尚未完成的方法。
七、Fixture（暂且翻译为“固定代码段”）
5）再来说点高级点的测试话题
一、高级Fixture
二、限时测试。
三、 测试异常
四、Runner (运行器)
五、 参数化测试。
六、 打包测试。
21.查看日志，并转成Debug模式，练习调试，学会查看单步执行时的变量值。
在控制台显示所有日志
开启项目debug模式
记一些常用的快捷键
查看变量变化
真是够了，debug模式竟然出不来！看了好多说法，都是java模式，找了半天没找到，原来在这里！！！
分别是show perspective；javaEE,java,debug;
最后再补上今天在一个博客上看到的硬货！
二：明天计划
部署服务器可是很感兴趣的，因为还想把我的毕业设计给放到自己的服务器上，明天走一下流程。
三：疑难问题
今天的最后一个debug貌似里面水很深，不能只是浅尝则止，以后肯定用得到！
四：思考总结
今天的maven配置过依赖文件之后的下载可是把我给吓住了，，这么容易？？哎呀，忘了，版本没改！！下了一堆以前的jar包，以后下手要慎重啊
task19-21