Testing with Visual Studio 2010

The last time I am discovering more and more the test features of Visual Studio 2010. In this blog item I discuss or mention some of these features.

It is possible to execute a code analysis after each developer build. You can enable (or disable) this in the properties of the project; see tab Code Analysis. There are several rules you can configure (globalization rules, basic correctness or of course you can customize these)
It is also possible to measure the quality of the code, with Code Metrics. Code metrics gives some overview in maintanability and complexibility. The code metrics can be used to give a progress overview in a refactor proces to the management, simply export this data to Excel. The index for maintability, complexibility, depth, code coupling and lines of code.
With the Test Impact Analysis feature Visual Studio shows you the tests which are affected on the code change. (use the Test Impace Window)
There are several tests; Code UI Test, Load Test and Web Performance test. You can also use profiling for your application. You can select CPU Samples, Instrucmentation and compare the results and find the method or class which is the most expensive.

Load Tests in Visual Studio

With the help of Visual Studio you can setup a Load Test. A little part of the Load Test is a Web Performance Test (prev. Web Test). A requirement for executing the test again and again without having recording it again is that the ids of the web controls are the same, between postbacks AND IIS restarts. If this is NOT the test will fail, you can solve this by making the web control id constant or maybe you can create an Extraction Rule

Unit testing losse flarden

Wanneer je start met unit testing, zijn er diverse handvaten die je kunt gebruiken om unit testing te gebruiken in je applicaties.
In de test logica mag je geen gebruik maken van
- IFs statements
- Switch of case statements

- Vervolgens moet de test code die je opstelt herhaalbaar uitgevoerd kunnen worden.
- Vermijd Multiple Asserts.
- Integration test en een unit test moet je scheiden
Alle testen in de solution runnen, wanneer een test failed dan is er een probleem. Dus -> betere test
-> integration test
-> er is geen configuratie maar je moet de test vertrouwen
Een verschil tussen een unit test en integration test is dat bij een integration test configuration noodzakelijk is. (gebruik de postfix unittest en integrationtest voor de desbetreffende testen)

Bij 'gewone' code geldt al gebruik GEEN magic numbers, en dit gaat ook op voor test code.

Syntax method names (bij testen
- method name
-state undertest
- expected behavior
-> dat leidt tot 'Add_LessThanZero_ThrowException'.

Helper methods
- '_make' -> create
- '_change' -> update
- '_assert_'

- Alleen public testen. DIt is een contract naar buiten toe. Private/protected is voor intern gebruik en meer verandelijk.
- Incremental work! (stapje voor stapje)
- [setup] attribut, dit is uitgevoerd voor ELKE test
- start een fail test, de test mag niet blijven 'falen' als de productie code is aangepast
- TDD -> vind de bugs sneller
- Simple code kan bugs bevatten
- Test names zijn lang maar dit is readabily (documentatie)
- Duplicated de logic in de test is een probleem, je test de logica niet. Het eindresultaat is niet gecontroleerd de bug wordt gewoon opnieuw gecreereerd in de Assert.AreEqual. Unittest mag geen logica bevatten, zelfs geen string.Format etc.
- Verander nooit een test. Als een test niet goed is (failuing test). Tegenstrijdige requirements vraag na welke requirement geldig is.
- Code coverage

How to start with Unit Testing?

I do not know how to start with Unit Testing. And I still don't...

So there are several blog items about Unit Testing, see
Unit Testing ASP.NET ASP.NET unit testing has never been this easy - Stefan Sedich's Blog. But what is the best way to start.

Can someone give me a good suggestion?

Update 16 july 2009: I have found a nice list with suggestions on Bugfree.

Test your website in mulitple browsers

On this blog there are some links for starting several browsers without installing them really on your system.
So you can easily test if your web site works well in the different versions of for example IE.

• http://www.xenocode.com/start/?a=Chrome
• http://www.xenocode.com/start/?a=ie6
• http://www.xenocode.com/start/?a=ie7
• http://www.xenocode.com/start/?a=ie8
• http://www.xenocode.com/start/?a=Safari
• http://www.xenocode.com/start/?a=Firefox