Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>One of the big advantages to having automated tests is that it gives you the confidence to change and fix things and to add features without worrying about the possibility that something will break, or that there will be unexpected side effects. It's easy and cheap to run pre-coded tests after every change, so you can make even the riskiest changes even late in the development cycle and still be confident that your application is still good.</p> <p>Another advantage is this: suppose that some new code you write <em>does</em> break or change some existing functionality. Then, you have an easy way to discover a list exactly what has changed (just run the automated tests and see the results!), and then you can reason about these changes, and classify them as either bugs, actually desired side effects/changes, etc. Otherwise, development quickly becomes a mess of "one step forward, two steps back" - every checkin might fix one problem and introduce two new ones. Even if the developer is aware of the two new problems (which isn't always the case), despite best intentions they will simply forget to address these new problems later on.</p> <p>You say that you can "just run an SP" or "just run" the UI yourself. But that doesn't scale... Again, ideally you'd want to be able to run 1000s of tests automatically after every change at no cost to you, which means they have to be automated. Also, you say that you know whether an SP is working just by running the application... but as your database and your application get more and more complex, it becomes less and less obvious what you have to do in your application to actually test your database properly. Also, what if later you need to create a 2nd application that uses the same database? (e.g. you now have a website, and later need to create some command-line tool for admins).</p> <p>All this becomes much more important when there are multiple people working on the same piece of code, for obvious reasons. Without good automated test coverage, complicated pieces of code quickly become one-person's-domain ("Don't touch that code without talking to Joe!").</p> <p>Of course, this does not mean that you should blindly apply all available test technologies to all projects, especially relatively "expensive" oves like CUIT (it's possibly expensive because if your UI changes a lot during the course of a project, this type of test can be harder to update). Instead, you should do a proper assessment of the real risk areas in your project (the "bug farms" if you will), and the right time in the cycle to introduce each type of testing - i.e. have an actual Test Plan. This last paragraph is my opinion, obviously there are different approaches to selecting what/how/when to test. </p>
    singulars
    1. This table or related slice is empty.
    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. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

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