在正常的测试中,当我们需要进行接口测试时,通常使用接口调试工具,如postman进行接口测试
目前我在尝试使用Go语言进行接口测试,使用的库均为Go自带的库.
注：当前采用的接口为时事新闻接口,每天可以请求100次,需要的同学,可以自行使用.
下面定义一个结构体类型和该类型的一个方法：
复制代码代码如下:
type User struct {
Name string
Email string
}
func (u User) Notify() error
首先我们定义了一个叫做 User 的结构体类型,然后定义了一个该类型的方法叫做 Notify,该方法的接受者是一个 User 类型的值.要调用 Notify 方法我们需要一个 User 类型的值或者指针：
// User 类型的值可以调用接受者是值的方法
damon.Notify()
// User 类型的指针同样可以调用接受者是值的方法
alimon.Notify()
①.、学习曲线
它包含了类C语法、GC内置和工程工具.这一点非常重要,因为Go语言容易学习,所以一个普通的大学生花一个星期就能写出来可以上手的、高性能的应用.在国内大家都追求快,这也是为什么国内Go流行的原因之一.
Go拥有接近C的运行效率和接近PHP的开发效率,这就很有利的支撑了上面大家追求快速的需求.
Go语言可以说是开发效率和运行效率二者的完美融合,天生的并发编程支持.Go语言支持当前所有的编程范式,包括过程式编程、面向对象编程以及函数式编程.
这包括互联网应用、系统编程和网络编程.Go里面的标准库基本上已经是非常稳定,特别是我这里提到的三个,网络层、系统层的库非常实用.
我相信这一点是很多人选择Go的最大理由,因为部署太方便,所以现在也有很多人用Go开发运维程序.
它包含降低心智的并发和简易的数据同步,我觉得这是Go最大的特色.之所以写正确的并发、容错和可扩展的程序如此之难,是因为我们用了错误的工具和错误的抽象,Go可以说这一块做的相当简单.
Go拥有强大的编译检查、严格的编码规范和完整的软件生命周期工具,具有很强的稳定性,稳定压倒一切.那么为什么Go相比于其他程序会更稳定呢?这是因为Go提供了软件生命周期的各个环节的工具,如go
tool、gofmt、go test.
所谓Go语言式的接口,就是不用显示声明类型T实现了接口I,只要类型T的公开方法完全满足接口I的要求,就可以把类型T的对象用在需要接口I的地方.这种做法的学名叫做Structural Typing,有人也把它看作是一种静态的Duck Typing.除了Go的接口以外,类似的东西也有比如Scala里的Traits等等.有人觉得这个特性很好,但我个人并不喜欢这种做法,所以今天这一节谈谈它的缺点.当然这跟动态语言静态语言的讨论类似,不能简单粗暴的下一个"好"或"不好"的结论.
我的观点:
Go的隐式接口Duck Typing确实不是新技术, 但是在主流静态编程语言中支持Duck Typing应该是很少的(不清楚目前是否只有Go语言支持).
静态类型和动态类型虽然没有绝对的好和不好, 但是每个都是有自己的优势的, 没有哪一个可以包办一切. 而Go是试图结合静态类型和动态类型(interface)各自的优势.
那么就从头谈起：什么是接口.其实通俗的讲,接口就是一个协议,规定了一组成员,例如.NET里的ICollection接口：
public interface ICollection {
int Count { get; }
object SyncRoot { get; }
bool IsSynchronized { get; }
void CopyTo(Array array, int index);
这就是一个协议的全部了吗?事实并非如此,其实接口还规定了每个行为的"特征".打个比方,这个接口的Count除了需要返回集合内元素的数目以外,还隐含了它需要在O(1)时间内返回这个要求.这样一个使用了ICollection接口的方法才能放心地使用Count属性来获取集合大小,才能在知道这些特征的情况下选用正确的算法来编写程序,而不用担心带来性能问题,这才能实现所谓的"面向接口编程".当然这种"特征"并不但指"性能"上的,例如Count还包含了例如"不修改集合内容"这种看似十分自然的隐藏要求,这都是ICollection协议的一部分.
vi. 走；达到；运转；趋于
n. 去；进行；尝试
vt. 忍受；出产；以...打赌
[复数 goes 第三人称单数 goes 过去式 went 过去分词 gone 现在分词 going]
Go 由于不支持泛型而臭名昭著,但最近,泛型已接近成为现实.Go 团队实施了一个看起来比较稳定的设计草案,并且正以源到源翻译器原型的形式获得关注.本文讲述的是泛型的最新设计,以及如何自己尝试泛型.
例子
FIFO Stack
假设你要创建一个先进先出堆栈.没有泛型,你可能会这样实现：
type?Stack?[]interface{}func?(s?Stack)?Peek()?interface{}?{
return?s[len(s)-1]
func?(s?*Stack)?Pop()?{
*s?=?(*s)[:
len(*s)-1]
func?(s?*Stack)?Push(value?interface{})?{
*s?=?
append(*s,?value)
但是,这里存在一个问题：每当你 Peek 项时,都必须使用类型断言将其从 interface{} 转换为你需要的类型.如果你的堆栈是 *MyObject 的堆栈,则意味着很多 s.Peek().(*MyObject)这样的代码.这不仅让人眼花缭乱,而且还可能引发错误.比如忘记 * 怎么办?或者如果您输入错误的类型怎么办?s.Push(MyObject{})◆ 可以顺利编译,而且你可能不会发现到自己的错误,直到它影响到你的整个服务为止.
通常,使用 interface{} 是相对危险的.使用更多受限制的类型总是更安全,因为可以在编译时而不是运行时发现问题.
泛型通过允许类型具有类型参数来解决此问题：
type?Stack(type?T)?[]Tfunc?(s?Stack(T))?Peek()?T?{
func?(s?*Stack(T))?Pop()?{
func?(s?*Stack(T))?Push(value?T)?{
这会向 Stack 添加一个类型参数,从而完全不需要 interface{}.现在,当你使用 Peek() 时,返回的值已经是原始类型,并且没有机会返回错误的值类型.这种方式更安全,更容易使用.（译注：就是看起来更丑陋,^-^）
此外,泛型代码通常更易于编译器优化,从而获得更好的性能（以二进制大小为代价）.如果我们对上面的非泛型代码和泛型代码进行基准测试,我们可以看到区别：
type?MyObject?struct?{
X?
int
var?sink?MyObjectfunc?BenchmarkGo1(b?*testing.B)?{
for?i?:=?0;?i?b.N;?i◆◆?{
var?s?Stack
s.Push(MyObject{})
s.Pop()
sink?=?s.Peek().(MyObject)
var?s?Stack(MyObject)
sink?=?s.Peek()
结果：
在这种情况下,我们分配更少的内存,同时泛型的速度是非泛型的两倍.
合约（Contracts）
上面的堆栈示例适用于任何类型.但是,在许多情况下,你需要编写仅适用于具有某些特征的类型的代码.例如,你可能希望堆栈要求类型实现 String() 函数