Niflheim World

Welcome to Niflheim !

  • First 5 messages from new users (pre-moderated user) will be checked for flood/spam before being posted on the forum. Users will also be checked for a multi-account.
    If you want to communicate without delay, get a free Huscarl status (how to get - User Groups), or buy premium status (how to buy - Premium status)
  • We have a scammer on our forum who poses as the administrator of our forum in his telegram channel.
    Scammer screen group - Screen 1, Screen 2 and group name - https://t.me/Niflheimworld (This is not an admin, the link is only for reference with whom not to conduct transactions)
    Do not trust him and do not conduct transactions with him!
    The administrator has only one telegram - @ftmadmin and our chat - Link on chat

Programming The Art of Unit Testing with Examples С# (2014). Roy Osherove


Redman

Forumteam
Staff member
Tignarman
Joined
Aug 24, 2020
Messages
17,684
Reaction score
24,011
NL COIN
89,731
1604835662793.png

One of the biggest failed projects I worked on had unit tests. Or so I thought. I was leading a group of programmers creating a billing application, and we were doing it in a fully test-driven manner—writing the test, then writing the code, seeing the test fail, making the test pass, refactoring, and starting all over again.

The first few months of the project were great. Things were going well, and we had tests that proved that our code worked. But as time went by, requirements changed. We were forced to change our code to fit those new requirements, and when we did, tests broke and had to be fixed. The code still worked, but the tests we wrote were so brittle that any little change in our code broke them, even though the code was working fine. It became a daunting task to change code in a class or method because we also had to fix all the related unit tests.

Worse yet, some tests became unusable because the people who wrote them left the project and no one knew how to maintain the tests or what they were testing. The names we gave our unit testing methods weren’t clear enough, and we had tests relying on other tests. We ended up throwing out most of the tests less than six months into the project.
The project was a miserable failure because we let the tests we wrote do more harm than good. They took more time to maintain and understand than they saved us in the long run, so we stopped using them. I moved on to other projects, where we did a better job writing our unit tests, and we had some great successes using them, saving huge amounts of debugging and integration time. Since that first failed project, I’ve been compiling best practices for unit tests and using them on subsequent projects. I find a few more best practices with every project I work on.

Understanding how to write unit tests—and how to make them maintainable, readable, and trustworthy—is what this book is about, no matter what language or integrated development environment (IDE) you work with. This book covers the basics of writing a unit test, moves on to the basics of interaction testing, and introduces best practices for writing, managing, and maintaining unit tests in the real world.

 
shape1
shape2
shape3
shape4
shape7
shape8
Top