一个测试程序迭代的故事01

Posted 2020-12-09 unjiang

一个测试程序迭代的故事

 

缘起

大学的时候学的是C，毕业以后听说聪明的程序员用Delphi，从那时起就开始了这段缘分。2000年已经有了Delphi5，多功能和高效率深入人心。随着多年的演进和众多开发者的奉献，如今功能更多，效率也更高。但是好工具也要配合好方法去使用，更要探索适合自己的方法。

探索提高效率的方法就是这个故事的主要内容。

 

第一个需求 测试一段代码

每一个开发者，无论是在学习阶段，还是在实践阶段，都会做一件事情，测试代码。

最简单的方法，就是新建一个工程，放一个按钮，修改标签，双击按钮，在Click事件中写一段代码，然后编译运行程序，点击按钮，观看代码的作用。这一套行云流水的操作，简直成了开发者的站桩功夫，不要太熟练！

很多入门书籍也都是从这个站桩功夫开始的，很多网上分享的文章也都是这么做的，包括人气很旺的“万一的 Delphi 博客”。

简单就真的简单吗？

 

第二个需求 测试多段代码

测试了第一段代码后，再测试一段代码怎么做？再新建一个工程？还是打开原来的工程，再放一个按钮？

哈哈，迭代开始了！（这里应该有字幕：“迭代 即 黑格尔辩证法的无限循环”）

第一个方案：再新建一个工程？

重复了很多步骤，多占了磁盘空间，以后再次查阅或修改也不方便！

但也许这些都不是问题，可以不保存工程，直接把代码和结果以文字描述或图片的形式保存到一个笔记软件或博客就行了。重复的步骤大部分是IDE完成的，自己只是点击几下鼠标，查阅功能也交给了笔记软件或博客。以后想修改一点代码再次测试的时候，重复一下站桩功夫就好了。

不过，如果代码涉及组件，记录和恢复就不那么简单了，直接把窗体文件转成文字一起保存是一个方法，但增加了很多无关的内容。

第二个方案：打开原来的工程，再放一个按钮？

测试代码再多呢？窗体上总有放满的时候，再说，按钮多了也容易搞混，找到要测试的按钮都要花点时间。分类放到不同的工程中，又回到了第一个方案。还可以在一个工程中多建几个窗体，分类放置按钮，这样更高效一些。

一个工程，多个窗体，分类放置按钮，这样改进目前看还不错。

看来吃一顿饭是一种需求，顿顿有饭吃却是新的需求，量的变化会导致需求的变化。

1到n，就这样了吗？

 

第三个需求 多一点信息标识代码

写了一些测试代码后，有一天想再看看某一段测试代码的效果，结果发现很难找到那个按钮。标签写的太简单了！放置按钮的时候还知道，过后就忘了。

这个简单，标签写详细一点就好了！连迭代都不算。

改起来却发现不那么简单。文字多了，按钮就要变大，占的地方就大。有的按钮字多，有的字少，大小不一，很不美观。要是统一大小，占的地方就更大，而且还要浪费时间设置大小和位置。

还是要迭代！

菜单可以显示更多的文字，而且占的地方不大。而且菜单是树形结构，可以添加子菜单，用于分类测试代码很适合。

按钮改成菜单项的工作量变化不大。打开测试工程，打开相关窗体，打开MainMenu编辑器，插入一个MenuItem，设置标签，双击菜单项，在Click事件中写代码，然后编译运行程序，点击菜单项，观看代码的作用。

不太好的地方就是运行后，要点击主菜单，才能看到子菜单。

瑕不掩瑜，可以接受。

一时爽不等于时时爽，如果以后的路还很长，还是一开始就把事情做完善一点。

微瑕，需要改进吗？