Tag Info

Basically your problem is you are trying to squeeze two months of work into one, make yourself super efficient while also dealing with an inordinate amount of code, and a large group of people who are claiming that you are slowing them down. All true, and while all of the answers given will help, you will also need to use some diplomacy in being able to ...

You have many excellent answers already. Adding my 2 cents to say that your story hits close to home. Management and I have come to an agreeable compromise which is that I created "Mini regression" test scenarios for only the high traffic areas and modules of the program. The Mini Regression is performed as needed, but usually during installation testing. ...

I know this problem way too well. There's no "right" answer, unfortunately, but there are some things you can do to help with this problem. Dependency map - do you have a list of application features that have heavy dependencies and tend to break when changes occur in other areas? If you know changes in feature X tend to break feature Y, you know you ...

I have encountered exactly the same problem and there is no "right" answer, but I can share with you what I've learned: 1) Code changes in one place can cause problems in another. Unless your project is so incredibly well documented that you know exactly what a change can impact, testing the full application on releases is important. 2) Find a balance ...

Firstly, I've been exactly where you are and I know the pain you're going through. It's also very 'cool' at the moment for everyone to talk about 'Automation' and how it's a 'golden ticket' to Continuous Integration. Everybody wants their stuff out fast. There are ways to tackle this, but personally, I think a lot of comes with having an understanding of ...

I'll throw out a couple of definitions so I can answer the question with an esoteric and abstract response: A functional piece of code is any operation that makes changes to a finite system (in other words, a computer.) It is important to realize that there are only a finite number of configurations that can occur on a computer. Obviously, a functional ...

Even theoretically, unit testing isn't sufficient because it doesn't cover the paths through the system. You can cover every line of code in a system, but not cover every potential way through it. For instance, can you launch the application? Does it run on all the target operating systems? Does it render correctly? These are all out of the scope of unit ...

There are many cases where unit testing as you have described would not be "sufficient". (And you haven't really defined what you mean by "sufficient" in this case. Good enough to move the code to Production? Good enough to pass it on to QA? Good enough to please your boss? Good enough to feel like you did a good job? Something else?) In most practical ...

Not exactly. Unit testing only isolates units in isolation. In these tests all dependencies to other units are mocked or stubbed out. So how do you know those units together do what they are supposed to do? Code tends to grow hierarchically in complexity, and with that growth comes more and more units working together, more and more groups of units ...