问题解决技巧？ [英] Problem Solving Techniques?

问题描述

我们是否应该首先编写一个算法然后修改它以掩盖所有的测试用例或

我们应该根据测试用例设计我们的算法???

Whether we should write an alogrithm first and then modify it to cover up all the test cases or
we should design our algorithm according to test cases???

推荐答案

我认为 ThePhantomUpvoter 是正确的：你应该使用更适合的技术：

• 问题的复杂性。
• 你的技能。

I think ThePhantomUpvoter is correct: you should use whatever technique is more appropriate for:

• The problem complexity.
• Your skills.

你在问什么测试驱动开发（TDD）的概念在某种程度上至关重要，它正在成为比最佳实践更多的编码宗教。我是一个学习新技巧的老狗，除非我已经尝试并且探索了大部分角落，否则通常不会批评某些东西。



我想我正确理解了这些问题围绕TDD及其试图解决的问题，但我还没有转换为编写API的核心概念，然后是对它的测试，然后是实际的代码。



如果你问其他十个同样的问题，你可能会得到4或5个独特的意见。

What you are asking is somewhat central to the idea of Test Driven Development ("TDD"), which is turning out to be more coding religion than a best practice. I am an old dog learning new tricks and don't typically criticize something unless I have tried it and explored most of the corners.

I think I properly understand the issues surrounding TDD and the problems it is trying to solve but I have not been a convert to the central notion of writing an API, then the tests for it, then the actual code.

If you ask ten other people the same question you will likely get 4 or 5 unique opinions.

我有两个关于测试用例的建议：



简要说明：

1.有时（通常）你根本不需要测试用例。

2.最重要的是定义图书馆的界面很好。在接口两侧实现代码的顺序并不重要（品味问题）。接口的一端包含库本身的代码，另一端包含不同的程序/其他库（包括计为lib的一个用户的测试用例）。我在这里添加一个重要的注释：世界并不完美，需求经常变化。不要梦想完美的界面，也不要花费数周的时间来设计它。有时在扩展时必须更改界面是不够的，在这种情况下你必须调整库代码和库用户的代码（包括程序和测试用例）。



我已经研究了一些使用大量单元测试的大型代码库。与此同时，我看到没有单一测试用例的滚动和成功的大型项目。有些项目（比如我目前正在开发的项目）只有一些库（例如我们的内置脚本编译器）的测试用例，但是我们的构建（最终构建的产品）及其核心功能一直在测试中（我们有一个有少数QA专业人士的部门）。我们产品的大部分代码变化太快，因此单元测试的成本将超过我们通过单元测试获得的优势。



何时进行单元测试？单元测试有几个优点和缺点。



- 优点：

轻松引入新功能而不会搞砸旧功能（你可以测试修改代码后的旧功能）。如果某些库的可靠性很重要，那么必须为它们编写测试（例如飞机控制软件中使用的库）。我认为的另一个优点是：对于测试用例，库接口至少有2个用户：在最终产品中使用库的程序和测试用例（这是使用lib的另一个程序），这迫使人们定义更清晰的接口和自动阻止一些懒惰的编码器将功能的一半代码推送到另一个图书馆 - >更好地分离源代码级别的问题。



- 缺点：

如果代码库是经过测试的，那么测试代码可以是一半或者更多整个代码库！这涉及额外的维护，这可能是非常昂贵的（时间/金钱），具体取决于旧代码的变化频率。在快速变化的代码中，有时候测试会极大地减慢开发过程。出于这个原因，有时唯一被测试的接口是用户界面和QA人员现成的编译程序的重要功能。 :-)



最后，开发几乎总是关于时间和金钱。贵公司的某个人必须决定测试用例在特定情况下是否有用/无用，以及您是否有时间/资金投入测试用例的优势。说单元测试总是好的并不公平，有时候你支付的费用远远超过单元测试所得的费用。

I have two advices regarding test cases:

Briefly:
1. Sometimes (often) you don't need test cases at all.
2. The most important thing is to define the interface of the library well. The order in which you implement code on the two sides of the interfaces is unimportant (matter of taste). One side of the interface contains the code of the library itself, the other side contains different programs/other libs (including the test cases that counts as one user of the lib). I add an important note here: The world ins't perfect and requirements often change. Don't dream about the perfect interface and don't spend weeks designing it. Sometimes the interface must be changed when extending it isn't enough and in this case you have to adjust both the library code and the code of the library users (including the programs and test cases).

I have worked on some large codebases that made use of extensive unit testing. At the same time I've seen rolling and successful large projects without a single test case. Some projects (like the current one I'm working on) has test cases only for some of the libraries (for example our builtin script compiler) but our build (final built product) and its core features are constantly under testing (we have a department with a few QA professionals). Most of the code of our product changes too rapidly so the costs of unit testing would outweigh the advantages we would gain by unit testing.

When to make unit testing? Unit testing has several advantages and disadvantages.

- Advantages:
Easy to introduce new features without screwing up old features (you can test the old features after modifying the code). If the reliability of some libraries is important then writing tests for them is mandatory (for example libs used in the control software of an airplane). Another advantage in my opinion: with test cases the library interface has at least 2 users: The program that uses the library in the final product and the test case (that is another program using the lib) and this forces people to define cleaner interfaces and automatically prevents some lazy coders to push half of the code of a functinality to another libarary -> better separation of concerns on source code level.

- Disadvantages:
If a codebase is exensively tested then the test code can be half or more of the whole codebase! This involves extra maintenance that can be extremely costly (time/money) depending on the frequency of changes in old code. In rapidly changing code sometimes testing would terribly slow down the development process. For this reason sometimes the only interface that is tested is the user interface and important functionalities of the ready-made compiled program by QA people. :-)

Finally development is almost always about time and money. Someone at your company has to decide whether test cases are useful/useless in a given scenario and whether you have the time/money to invest for the advantages of test cases or not. Saying that unit testing is always good isn't fair, sometimes you pay much more than what you gain by unit testing.

这篇关于问题解决技巧？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！