Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>1) I use TestDriven.Net, and I like it so a +1 from me for that<br/> 2) Code coverage is useful, when thought about in the right frame of mind:<br/> <strong>High code coverage does not necessarily mean high quality unit tests, but...<br/> High quality unit tests does mean high code coverage</strong></p> <p>I've only used NCover, so can't recommend alternatives.</p> <p>Regarding mocking - once you grasp what it is about and what it really means for you, you will see the benefits it has to offer. Namely, it means you're not dependent on the integration of the code you're testing with an outside dependency, and also helps to keep text execution time down (e.g. mocking your data access layer prevents costly interaction with the DB). That is an important factor in my opinion as if tests take a long time to run, people can start to not bother running them if it means they have to wait too long! I use NUnit, which has support for mocks built-in.</p> <p>Tie a TDD approach into a continuous integration environment (e.g. <a href="http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET" rel="nofollow noreferrer">CruiseControl.NET</a>), and you have a very powerful and productive setup.</p> <p>When starting out in TDD/unit testing, I'd always recommend writing tests for code written from "now" onwards and not focussing too much on writing tests for legacy/existing code. That is a lot harder to do in general and a lot more expensive time-wise, particularly if the code is old/not fresh in anyone's mind!</p> <p><strong>Update:</strong> To explain my last point a bit further, in response to Robert's comment...</p> <p>When you are trying to get up and running with TDD/unit testing, and gain momentum with the whole team, you want that to be as positive and productive as possible. Writing tests for old code that isn't being changed during this initial period is expensive compared to new code because the code is not fresh, the exact intricacies of it more than likely have to be worked out again and not necessarily by the original programmer. Plus the fact that you may well find it difficult to justify to the business, the time needed to spend revisiting old code to write tests for them, instead of working on new functionality/fixing real bugs/issues. </p> <p>It can become a negative experience-a developer who is tasked writing the tests for old code he knows/remembers little about will find it more difficult to do and thus their first experience is not a positive one. You do need to be careful too in this situation as you may end up with weak tests which gives you false confidence. In my experience, it's absolutely critical that everyone gets off to a positive start with this, else confidence/motivation in it fades and the end result is much worse. </p> <p>I'm <em>not</em> actually saying you should not add tests for legacy code - I do myself when I work in or around older code that doesn't have any tests in order to bit-by-bit, improve the test coverage and quality. The difference is, I'm already onboard with the process, a "believer". It's the early stages of it, that are key...hence my point about not focussing <em>too much</em> on the legacy code at the start.</p>
    singulars
    1. This table or related slice is empty.
    1. POGetting Started with TDD?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USAdaTheDev
    1. USAdaTheDev
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COYour comment about not unit testing the legacy code is absolutely backwards. You need to establish a good suite of unit tests on the legacy code base so that you can refactor safely, without worrying about breaking something.
      singulars
      1. PO
      1. USRobert Harvey
    2. CO@Robert - I don't think it's backwards at all. I've clarified my opinion above.
      singulars
      1. PO
      1. USAdaTheDev
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload