Agricoltura, GOTO 2013 • JS Unit Testing Good Practices & Horrible Mistakes • Roy Osherove
agricoltura | info | prezzo | dati | produzione
This presentation was recorded at GOTO Aarhus 2013
http://gotocon.com
Roy Osherove - Senior consultant at ITVerket AS
ABSTRACT
In this talk, Roy Osherove, author of The Art of Unit Testing 2nd Edition, shares common pitfalls in writing unreadable, unmaintainable unit tests in javascript. Some simple rules can keep you from tearing your hair out in anger three months from now, when things need to change, and you can see them all in this talk. more info at ArtOfUnitTesting.com
https://twitter.com/gotocon
https://www.facebook.com/GOTOConference
http://gotocon.com
Commento
-
Roy, great talk! Loved it all!
-
This is one of Roy's best presentations imo. Excellent unit testing advice that applies far beyond .NET
-
People upset by my comment are the fat anti-social know-it alls who actually produce little and intimidate companies into hiring them. They use unit tests to try and stop the flow of change at the detriment of their companies. The only constant is change. Unit tests were invented to solidify code, which is wrong. All effort should be made to change and adapt. Nothing ever finishes. To think there is a finished point capable of testing is false. Everyone making new products will defeat you. Unit tests are cancer or at best training wheels!
-
Unit Tests == People who have given up on life and are looking for more excuses to site behind a computer and belittle everyone else. || People who gave up on software development and now just want to write tests and not worry about implementation || Missed opportunity to be writing software that makes money while your competition is adding features || Blowing up the thing things that don't matter in life to the largest possible format || Solidifying anything in a world where the only constant is change. A better answer is letting the world be your unit test. Fix it when it breaks. You cannot predict everything. Do end to end tests. Testing a method, like a cell outside of it's body tells you nothing about the whole product functioning, which the only thing that matters. We write code to solve real life problems, not to write code.
This presentation was recorded at GOTO Aarhus 2013 http://gotocon.com Roy Osherove - Senior consultant at ITVerket AS ABSTRACT In this talk, Roy Osherove, author of The Art of Unit Testing 2nd Edition, shares common pitfalls in writing unreadable, unmaintainable unit tests in javascript. Some simple rules can keep you from tearing your hair out in anger three months from now, when things need to change, and you can see them all in this talk. more info at ArtOfUnitTesting.com https://twitter.com/gotocon https://www.facebook.com/GOTOConference http://gotocon.com
Commento
Roy, great talk! Loved it all!
This is one of Roy's best presentations imo. Excellent unit testing advice that applies far beyond .NET
People upset by my comment are the fat anti-social know-it alls who actually produce little and intimidate companies into hiring them. They use unit tests to try and stop the flow of change at the detriment of their companies. The only constant is change. Unit tests were invented to solidify code, which is wrong. All effort should be made to change and adapt. Nothing ever finishes. To think there is a finished point capable of testing is false. Everyone making new products will defeat you. Unit tests are cancer or at best training wheels!
Unit Tests == People who have given up on life and are looking for more excuses to site behind a computer and belittle everyone else. || People who gave up on software development and now just want to write tests and not worry about implementation || Missed opportunity to be writing software that makes money while your competition is adding features || Blowing up the thing things that don't matter in life to the largest possible format || Solidifying anything in a world where the only constant is change. A better answer is letting the world be your unit test. Fix it when it breaks. You cannot predict everything. Do end to end tests. Testing a method, like a cell outside of it's body tells you nothing about the whole product functioning, which the only thing that matters. We write code to solve real life problems, not to write code.