Smidig

Hvordan bør man kjøre utviklingsprosesser? Hvordan ivaretar man alle interessenter? Hvordan sikrer man at man utvikler det virksomheten faktisk trenger med riktig kvalitet? Og ikke minst: Hvordan skaper man entusiasme og energi i teamet? Dette skriver vi om i denne bloggen.

Autotest

Thoughts on Unit Testing in Asp.NET MVC

I have been working with TDD and Mvc in different flavors for 10 years now. The last 2 years I have been working with Asp.Net Mvc. I have written down some thoughts on unit testing in an Mvc app with principles that I have come to value. These principles help me write good maintainable tests. Much of it also applies to unit testing in general.

Unit Testing in General.

When writing tests it is important to think about responsibilities. Tests should also follow the principles of DRY(Do not Repeat yourself). You should only test the things an object is responsible for. If you test more you will duplicate tests. This results in fragile tests that require a lot of attention to keep the build green. Test object behavior not functions. Do not test functionality of other objects. That should be done in separate test classes for the external objects. You can and will have to use other objects in test cases, but bear in mind the responsibility of the object at hand.

Over view of what to test

View: Ideally you should test java scripts and rendered views. For view tests test for what is the views responsibility. The views responsibility is layout and presentation. Test that data is updated in the correct place and that the view is rendered in a certain way given a specific model. Only test the rendering logic. For Ajax functionality e.g. test that the UpdateTargetId is changed. Do not test the values. What values are set should be a model or business logic responsibility. If you have to test the values your view is probably doing too much. Consider separate view models to ease unit testing of view logic.

Controller: The controller is responsible for delegating actions and events from view to model. As a rule of thumb we can say that you should only test that the controller returns the correct view and model. If you need to test any ting else your controllers are probably doing to much. Consider to move responsibilities out of the controller to other objects.

Business Logic and model: Test the responsibility of the objects. Her you test calculated values and results of business rules. Decouple your logic from external resources. It is hard to test if your model is tightly bound to a database or SharePoint. Configuring a model for testing in code should be easy. If it’s hard and requires a lot of code consider refactoring.

Data access layer/ integration layer: Consider integration tests. It is hard to write unit tests at this level. Mocking often results in testing that your code is written according to your assumptions. If your assumptions are wrong your code will still pass.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

Du kan bruke disse HTML-kodene og -egenskapene: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

retro_threecol_redcross

Retrospectives without post-its?

Two Bouvet consultants, Morten Granum and myself are currently working with a team to introduce some elements from Kanban and..

Bilde fra kontorlandskap

Min dag i et konsulentselskap

Hvordan foregår det egentlig når nettsider og digitale løsninger skal utvikles? Dette prøvde jeg å finne ut da jeg besøkte..

Hva er Kanban?

Det finnes mange ulike beskrivelser av Kanban.  Er du interessert i å vite litt mer om hva det egentlig er?..

Jenkins

Android App With Jenkins

I just got involved with a mobile project, and had to let my inner devop out for a moment… So, here’s..

Finne rett audience i SharePoint

Samhandlingsplattformen SharePoint har mulighet for å personalisere komponenter gjennom bruk av audiences. Hvis du jobber med konfigurering av SharePoint, så har du kanskje hatt problemer med å vite hvilke brukere et audience i SharePoint inneholder. Eller problemer med å finne et audience som faktisk av er interesse for deg innenfor den gitte SharePoint applikasjonen du benytter?

SONY DSC

Når kunnskap og karisma erstattes av kustus

Interaksjonsdesignere er fremdeles fremmedkulturelle i mange utviklingsmiljøer. De er i tillegg en knapp ressurs, og sitter ikke nødvendigvis sammen med utviklerne hver dag, hele dagen. Hvordan skal vi da jobbe smidig sammen?

En praktfull eske fra pappverket

Den triste IT-historien om Pappverket

Alle trenger pappesker. Grunnet eskemangelen i mellomkrigstiden bestemte myndighetene seg for å rasjonalisere og sentralisere produksjonen og tildelingen. Slik oppsto..

Smidig

Hvordan bør man kjøre utviklingsprosesser? Hvordan ivaretar man alle interessenter? Hvordan sikrer man at man utvikler det virksomheten faktisk trenger med riktig kvalitet? Og ikke minst: Hvordan skaper man entusiasme og energi i teamet? Dette skriver vi om i denne bloggen.