Testing is a vital part of writing software - any kind of software. Whether you are writing a little routine to sort numbers, or a system to launch space ships to Mars.
Now it used to be that developers would write their code, and then exercise it by hand - often in a debugger - to verify that it did what they expected. This was a painful and tedious way to test their code. Not only was it tedious and painful - but it wasn't repeatable. This meant that every time you made a change you had to manually repeat the tests and hope you didn't forget anything or do things slightly differently. Quality suffered - and there was much sorrow and weeping.
Eventually, developers realized that they could write a separate program that would exercise their code by running it through the conditions that they expected it to handle, and having that code verify the results. Things started to get better. This approach to testing was often called a test harness.
Writing test harnesses helped, but there was a lot of repetitive code - there is quite a bit of infrastructure related to running and verifying tests. However, some really smart developers out their said: "We're not going to write boiler plate code over and over ... we'll make a library to do it for us."And so unit testing tools like JUnit and NUnit (and many others) were born.
These libraries (and tools) help you structure, organize, and execute your tests. They provide convenient methods to verify conditions, trap and trace exceptions, and report which tests passed and which ones failed. Finally, developers could focus on the important part: writing the tests and verification logic that would help assure that the code they wrote worked. These tests were repeatable. They could be run as part of an automated build process. They could be handed down through the generations and added to by others as new failure points were found and fixed. They could be re-run by the original developer months and years after the original code had been written to make sure things still work.
If you plan to be a successful software developer at any level, in any size organization (even if it's just yourself) - you should learn about - andembraceunit testing.
Testing is quite an important part of programming (In my opinion), so if you (or someone else) changes a part of code, and it happens to break something down the line, your tests should pick this up.
Well, that's how I see it, I'm still new to unit testing.
An Example.
Lets say I have a method
Add(int a, int b)
{
return a + b;
}
My Unit Test would be:
[Test]
public void Test001_TestAdd()
{
Assert.IsTrue(Add(1,3) == 4);
}
If someone changed the Add Method to lets say:
Add(int a, int b)
{
return a * b;
}
My Unit test would fail, and could potentially save a life (if you work in medical software, or for NASA), or stop a potential bug :)
Now if they had Unit Tests, this may not have happened, simple problem, missed.
Absolutely. Unit testing is one of the most important concepts to learn in modern software development.
It doesn't matter if your programs are scientific simulations, enterprise applications, etc. neither if you are in a big team or if you code alone (but in big teams is as important as compiling your code).
Every programmer should learn it. Now, will every programmer use it? Likely not, but they should know it anyway.
Unit testing is very, very common nowadays, and understanding how it works is essential in any project other than the little hobby ones you're writing right now. Use the time you have now and get ready for your future. Also learn about Mock objects (related).
Unit testing has many values, depending on what you do and what projects you work on different parts of unit testing will be important to you.
At very least you should learn the basics of unit testing to have a fully rounded sense of the development process. As time goes on and you work on larger projects you will find that unit testing is an integral part of maintaining and growing large codebases.
I've found that if you can get a ReSharper license (Visual Studio plug-in that does many things) that the running of unit tests becomes so quick and easy that writing them really does become a no-brainer, even for small pieces of work.
发布评论
评论（6）
测试是编写软件（任何类型的软件）的重要组成部分。无论您是编写一个对数字进行排序的小例程，还是编写一个向火星发射宇宙飞船的系统。
现在，开发人员过去会编写代码，然后手动执行它（通常在调试器中）以验证它是否达到了他们的预期。这是测试代码的一种痛苦且乏味的方法。这不仅乏味且痛苦 - 而且不可重复。这意味着每次进行更改时，您都必须手动重复测试，并希望您不会忘记任何事情或做的事情略有不同。 质量受到影响 - 并且有很多悲伤和哭泣。
最终，开发人员意识到他们可以编写一个单独的程序，通过在他们期望它处理的条件下运行代码来锻炼他们的代码，并拥有代码验证结果。 事情开始变得更好。这种测试方法通常被称为测试工具。
编写测试工具很有帮助，但有很多重复的代码——有相当多的基础设施与运行和验证测试相关。然而，一些真正聪明的开发人员表示：“我们不会一遍又一遍地编写样板代码......我们将创建一个库来为我们做这件事。” 单元测试工具如 JUnit 和 NUnit（以及许多其他）诞生了。
这些库（和工具）可帮助您构建、组织和执行测试。它们提供了方便的方法来验证条件、捕获和跟踪异常以及报告哪些测试通过了，哪些测试失败了。最后，开发人员可以专注于重要的部分：编写测试和验证逻辑，这将有助于确保他们编写的代码有效。这些测试是可重复的。它们可以作为自动化构建流程的一部分运行。它们可以代代相传，并在发现并修复新的故障点时由其他人添加。它们可以由原始开发人员在原始代码编写数月甚至数年后重新运行，以确保一切仍然有效。
如果您计划成为任何级别、任何规模组织（即使只有您自己）的成功软件开发人员 - 您应该了解 - 并 拥抱 单位
这里有一些资源可以帮助您：
Testing is a vital part of writing software - any kind of software. Whether you are writing a little routine to sort numbers, or a system to launch space ships to Mars.
Now it used to be that developers would write their code, and then exercise it by hand - often in a debugger - to verify that it did what they expected. This was a painful and tedious way to test their code. Not only was it tedious and painful - but it wasn't repeatable. This meant that every time you made a change you had to manually repeat the tests and hope you didn't forget anything or do things slightly differently. Quality suffered - and there was much sorrow and weeping.
Eventually, developers realized that they could write a separate program that would exercise their code by running it through the conditions that they expected it to handle, and having that code verify the results. Things started to get better. This approach to testing was often called a test harness.
Writing test harnesses helped, but there was a lot of repetitive code - there is quite a bit of infrastructure related to running and verifying tests. However, some really smart developers out their said: "We're not going to write boiler plate code over and over ... we'll make a library to do it for us." And so unit testing tools like JUnit and NUnit (and many others) were born.
These libraries (and tools) help you structure, organize, and execute your tests. They provide convenient methods to verify conditions, trap and trace exceptions, and report which tests passed and which ones failed. Finally, developers could focus on the important part: writing the tests and verification logic that would help assure that the code they wrote worked. These tests were repeatable. They could be run as part of an automated build process. They could be handed down through the generations and added to by others as new failure points were found and fixed. They could be re-run by the original developer months and years after the original code had been written to make sure things still work.
If you plan to be a successful software developer at any level, in any size organization (even if it's just yourself) - you should learn about - and embrace unit testing.
Here are some resources to help you on your way:
是的，你应该使用它。 （或任何测试运行程序）
测试是编程的一个非常重要的部分（在我看来），因此，如果您（或其他人）更改了代码的一部分，并且它碰巧破坏了某些内容，那么您的测试应该 拿起这个。
嗯，这就是我的看法，我对单元测试还是新手。
一个例子。
假设我有一个方法，
我的单元测试将是：
如果有人将添加方法更改为：
我的单元测试将失败，并且可能会挽救生命（如果您在医疗软件或 NASA 工作），或者停止潜在的错误:)
现在如果他们进行了单元测试，这可能不会发生，简单的问题，错过了。
Yes you should use it. (or any test runner)
Testing is quite an important part of programming (In my opinion), so if you (or someone else) changes a part of code, and it happens to break something down the line, your tests should pick this up.
Well, that's how I see it, I'm still new to unit testing.
An Example.
Lets say I have a method
My Unit Test would be:
If someone changed the Add Method to lets say:
My Unit test would fail, and could potentially save a life (if you work in medical software, or for NASA), or stop a potential bug :)
Now if they had Unit Tests, this may not have happened, simple problem, missed.
绝对地。单元测试是现代软件开发中需要学习的最重要的概念之一。
如果您的程序是科学模拟、企业应用程序等，那么无论您在一个大团队中还是单独编码（但在大团队中与编译代码一样重要），都没有关系。
一本开始单元测试（针对 .net）的好书是 C# 中的实用单元测试NUnit
Absolutely. Unit testing is one of the most important concepts to learn in modern software development.
It doesn't matter if your programs are scientific simulations, enterprise applications, etc. neither if you are in a big team or if you code alone (but in big teams is as important as compiling your code).
A good book to start on unit testing (for .net) is Pragmatic Unit Testing in C# with NUnit
每个程序员都应该学习它。现在，每个程序员都会使用它吗？可能不会，但无论如何他们应该知道这一点。
如今，单元测试非常非常普遍，除了您现在正在编写的小爱好项目之外，了解它的工作原理对于任何项目都是至关重要的。利用你现在的时间，为你的未来做好准备。还可以了解 Mock 对象（相关）。
Every programmer should learn it. Now, will every programmer use it? Likely not, but they should know it anyway.
Unit testing is very, very common nowadays, and understanding how it works is essential in any project other than the little hobby ones you're writing right now. Use the time you have now and get ready for your future. Also learn about Mock objects (related).
单元测试有很多价值，具体取决于您所做的事情以及您在单元测试的不同部分所从事的项目对您来说很重要。
至少您应该学习单元测试的基础知识，以便对开发过程有一个全面的了解。随着时间的推移，您从事更大的项目，您会发现单元测试是维护和发展大型代码库不可或缺的一部分。
Unit testing has many values, depending on what you do and what projects you work on different parts of unit testing will be important to you.
At very least you should learn the basics of unit testing to have a fully rounded sense of the development process. As time goes on and you work on larger projects you will find that unit testing is an integral part of maintaining and growing large codebases.
如果您对测试驱动开发感兴趣，NUnit 是一个出色的工具。
请参阅我的回答此处有关 TDD 的一些注释。
我发现如果您可以获得 ReSharper 许可证（Visual Studio 插件可以< em>很多），单元测试的运行变得如此快速和容易，以至于编写它们确实变得轻而易举，即使对于小工作也是如此。
NUnit is an excellent tool if you're interested in Test-Driven Development.
See my answer here for some notes about TDD.
I've found that if you can get a ReSharper license (Visual Studio plug-in that does many things) that the running of unit tests becomes so quick and easy that writing them really does become a no-brainer, even for small pieces of work.