双十一|Java培训:如何在Java中有效地清除掩盖问题?

双十一|Java培训:如何在Java中有效地清除掩盖问题?

文章图片


因为软件缺陷会让我们在开发人员中显得很糟糕 , 并导致其他人对我们的看法降低 , 所以最好避免编写缺陷 , 快速识别和修复缺陷 , 或者掩盖我们的缺陷 。 有许多博客文章和文章讨论如何避免bug以及如何识别和修复bug , 因此 , 在这篇文章中 , 介绍一些最有效的策略 , 以彻底解决Java代码库中的问题 。 通过参加java培训 , 你可以学习更多java开发技能 , 提升自己 。
1.吞咽检查异常
当我们不小心在代码中引入了bug时 , 异常就是其中之一 。 在方法上声明throws子句或捕获已检查的异常也是一件麻烦事 。 这两个问题的解决方案都是在异常可能被抛出时捕获异常(即使它是正在运行时一场) , 而不执行任何操作 。 这使API保持简洁 , 对于检查的异常 , 人们几乎无能为力 。 通过不记录它或对它做任何事情 , 甚至没有人需要知道它曾经发生过 。
2.注释掉或删除不满意的单元测试
失败的单元测试可能会让人分心 , 并且很难确定新功能何时破坏了测试 。 它们还可以揭示我们在代码更改时破坏了某些东西 。 注释掉这些失败的单元测试将使单元测试报告更清晰 , 并且更容易查看是否有其他人的新功能破坏了单元测试 。
3.在基于JUnit的单元测试中使用@Ignore
注释掉失败的单元测试似乎令人不快 , 所以另一个可能更令人愉快的选择是用@Ignore注释失败的基于JUnit的单元测试方法 。 在java培训中 , 也有关于单元测试的学习 , 理论知识+实践项目 , 双管齐下 , 学以致用 , 让你深入浅出地学习java 。
4.完全删除单个测试
如果用@Ignore注释一个中断的测试或用@Ignore注释一个中断的测试是不令人满意的 , 因为有人可能仍然检测到我们破坏了一个单元测试 , 那么我们可以简单地将有问题的单元测试全部删除 。

5.注释掉令人不快的断言
我们不一定需要注释掉或删除整个测试 。 它可以简单到注释掉或删除单元测试方法中的断言语句 。 该方法每次都可以成功执行和运行 , 因为没有断言意味着没有失败的方法 。 当单元测试方法非常长且复杂 , 因此不容易发现缺少断言时 , 这种方法尤其有效 。
6.用无用和冗余测试的噪音分散注意力
注释掉单元测试 , 用@Ignore注释基于JUnit的单元测试 , 甚至删除单元测试 , 对于在Java中彻底解决问题来说 , 这些策略可能太明显了 。 为了使这些不那么明显 , 另一个有效的策略是在同一个单元测试类中编写大量不必要的和冗余的测试方法 , 这样看起来似乎正在进行全面的测试 , 但实际上 , 只有一小部分功能(我们知道的子集正在工作)正在进行测试 。 想要学习java更多知识和技能 , 可以考虑参加java培训 , 有经验丰富的专业讲师指导教学 , 有紧跟市场需求的实时课程 , 可以让你快速掌握这门技术 , 节约时间 , 少走弯路 。
7.编写单元测试 , 以“证明”您的代码是正确的 , 即使它不是
我们可以利用这样一个事实 , 即单元测试只能测试单元测试的作者认为被测试软件的预期行为 , 从而编写单元测试来证明我们的代码是正确的 。 如果我们将两个整数相加的代码在提供2和2时意外返回5的总和 , 那么我们可以简单地将单元测试中的预期结果也设置为5 。 给出了一份漂亮的单元测试报告 , 没有人会更明智 。
8.避免记录详细信息
日志可能会暴露软件问题 , 处理此风险的有效方法是根本不记录日志 , 只记录例行操作和结果 , 并在记录的消息中留下详细信息(尤其是上下文) 。 对平凡细节的过度记录也会掩盖任何可能暴露代码弱点的更有意义的消息 。