在.NET中存儲單元測試的常用方法[重復]

[英]Common approach to store unittests in .NET [duplicate]


Possible Duplicate:
Which is better? Unit-test project per solution or per project?

可能重復:哪個更好?每個解決方案或每個項目的單元測試項目?

From time to time i see different approaches:

我不時會看到不同的方法:

someone store unittest in the same project, which they currently testing, just creating test folder under the project root.

有人在他們目前正在測試的同一個項目中存儲unittest,只是在項目根目錄下創建測試文件夾。

Someone create additional test project for each project from solution they testing.

有人從他們測試的解決方案為每個項目創建額外的測試項目。

Someone have one big test project for all the tests from the whole solution.

對於整個解決方案中的所有測試,有人有一個大的測試項目。

So what is general and, lets say, "official" way to store tests in .NET world? Pretty sure that Microsoft have guidelines for that.

那么什么是一般的,並且,比方說,在.NET世界中存儲測試的“官方”方式?很確定微軟有這方面的指導方針。

3 个解决方案

#1


2  

First rule of test-code: Never ever put test code inside your production assemblies (the deliverables).

測試代碼的第一條規則:永遠不要將測試代碼放入生產裝配(可交付成果)中。

The reason for this rule is simple: Test code can potentially corrupt your on-site installation. Even with good coding practices. Even with good programmers.

此規則的原因很簡單:測試代碼可能會破壞您的現場安裝。即使有良好的編碼實踐。即使有優秀的程序員。

Second rule of test-code: It must be maintained by the programmers themselves: When the developers refactor their code, the test-code must change with it. Therefore dont put it in a separate solution if you can in any way avoid it.

測試代碼的第二條規則:必須由程序員自己維護:當開發人員重構代碼時,測試代碼必須隨之改變。因此,如果您能以任何方式避免它,請不要將其放在單獨的解決方案中。

From here on you are on your own. Personally I prefer to keep about a 1 to 1 correspondence between my production assemblies and my test assemblies, appending ".Test" to the name.

從這里開始,你就是靠自己。就個人而言,我更喜歡在我的生產裝配和我的測試裝配之間保持1對1的對應關系,並在名稱后加上“.Test”。

I then use this naming to filter them out when I do unit testing on the csproj files for production assemblies.

然后,當我對生產程序集的csproj文件進行單元測試時,我使用這個命名來過濾掉它們。

Oh did I mention that you should never put test code in production assemblies?

哦,我提到你不應該把測試代碼放在生產裝配中嗎?

#2


1  

This question seems a bit subjective, so you're likely to get a multitude of answers, and it will ultimately be up to you to decide what works best for you and your team.

這個問題似乎有點主觀,因此您可能會獲得大量答案,最終由您決定什么最適合您和您的團隊。

My $.02 ...

我的$ .02 ......

I generally expect to see tests in a different project than the code being tested. This keeps the resulting assemblies from getting bloated, and avoids having to deploy test code into production (or distributed to clients, depending on its purpose).

我通常希望在與正在測試的代碼不同的項目中看到測試。這可以防止生成的程序集變得臃腫,並避免必須將測試代碼部署到生產環境中(或根據其目的分發給客戶端)。

Regarding whether or not tests should be in the same project, or distributed across multiple projects depends on the tests that are being written. If the tests are all related, and it makes sense for them to be bundled together, then put them in one project, but if they're pretty unrelated, then I see no reason why they should be in the same project.

關於測試是否應該在同一個項目中,或者分布在多個項目中取決於正在編寫的測試。如果測試都是相關的,並且將它們捆綁在一起是有意義的,那么將它們放在一個項目中,但如果它們非常不相關,那么我認為沒有理由將它們放在同一個項目中。

I guess the judgment can be applied to tests the same as to any code. If it goes together, put it together, if not, then don't.

我猜這個判斷可以應用於任何代碼的測試。如果它在一起,把它放在一起,如果沒有,那么不要。

The fact that you are writing tests at all means you're probably on the right path, so don't be afraid to try something for awhile, decide if it works for you, and if not, try it a different way. The beauty of writing code is that it can be refactored over time to better suit your needs. :)

你正在編寫測試的事實意味着你可能正走在正確的道路上,所以不要害怕嘗試一段時間,確定它是否適合你,如果沒有,請嘗試不同的方式。編寫代碼的美妙之處在於它可以隨着時間的推移進行重構,以更好地滿足您的需求。 :)

#3


0  

This is what I have seen

這就是我所看到的

a) With larger teams with dedicated QA teams managing test code independently it as easier to manage your test code with its own solution.

a)大型團隊由專門的QA團隊獨立管理測試代碼,因此使用自己的解決方案更容易管理測試代碼。

b) With not so large teams where dev drives the unit tests and some functional tests it become easier to manager your tests as a part of the same solution.

b)由於不是那么大的團隊開發單元測試和一些功能測試,因此作為同一解決方案的一部分管理測試變得更容易。

c) And today with TDD being adopted more aggressively it becomes easier to simply have your tests as a part of your product code projects themselves.

c)今天,TDD被更積極地采用,簡單地將測試作為產品代碼項目本身的一部分變得更容易。

The guideline is to do place your tests where you find it best to manage them and it usually turns out to be either a or b for most people today.

指南是將測試放在最適合管理它們的地方,對於今天的大多數人來說,它通常是a或b。

UT: http://msdn.microsoft.com/en-us/library/hh598957.aspx

UT:http://msdn.microsoft.com/en-us/library/hh598957.aspx

TDD: http://msdn.microsoft.com/en-us/library/aa730844(v=vs.80).aspx

TDD:http://msdn.microsoft.com/en-us/library/aa730844(v = vs。80).aspx


注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:https://www.itdaan.com/blog/2013/01/26/72fbdd2743d08bca81dd46ba6963bd1b.html



 
粤ICP备14056181号  © 2014-2021 ITdaan.com