Tag Info

Hot answers tagged

20

There are 2 books I recommend reading as they will help with moving legacy code to TDD: Working Effectively with Legacy Code and Brownfield Application Development in .Net (newer book, but .NET based). Since I'm writing unit tests AFTER the code, should I first refactor, do my own regression tests, then continue using the TDD steps (write failing ...


15

I would suggest that you go back and do those unit tests when you are required to refactor that area of legacy code. The approach for do this is described in this question. When you are working with legacy code with no unit tests, its the same principle and techniques to add them regardless if you are doing TDD or not. I highly recommend Working ...


14

Well, first of all - congrats buddy, glad to know you work for customer / company with understanding that involving QA at early stages is definitely worth it! I'll reveal below several related points from my own experience of managing QA team (up to 10 FTE) involved in testing of fairly big project, where reqs page count was about 1000 pages and more, and ...


13

> The integration tests can sometimes take a long time, > thus discouraging users from running the entire test > suite prior to checking in For the checkin-runs you can mark the long-running tests with their own category and tell the test-runner to exclude those long-runners You may also look at Is there a way to separate long running (e.g. ...


11

Palindromes testing is very representative in terms of QA way of thinking. Moreover, writing tests dramatically increase the quality of task specification. When a QA engineer writes test cases, it well may happen that certain case is not covered in initial specs. This is a good reason for QA to come up with idea to improve those specs. So, when you are ...


10

Short answer: Yes you should unit test small projects. Longer answer: Like you said in your question, you currently test your code functionally. Why are you doing that? Because testing is useful! Unit tests are the same. If you ever go back to refactor your code, add or edit features a suite of unit tests will give you instant feedback that your ...


9

Welcome to SQA, Chris. First, regarding terminology, there are many terms for describing different kinds of testing. Everyone uses them differently. In some situations, those terms have specific meanings defined in contracts or regulatory documents. Usually though, the terms are just labels assigned to vague concepts that individuals (rather they realize ...


9

How much testing is sufficient? Meaning, what's the minimum effort required to test reliability? When looking at the question of "how much testing?" you have to consider "how lucky do you feel?" You could do no testing at all if you feel really lucky, or if the consequences to being wrong are extremely low. You could test everything for a really long ...


7

What you have described so far is something I'd call 'scrummerfall', but given how it often turns out, could be spelled scrummerFAIL instead. I see several issues that need to be addressed. @Aruna covered several in their answer, which gets high marks from me. To what they have said I would add the following. 1) the team doesn't understand what 'DONE' ...


7

In agile environment the distinction between a tester and a developer is blurred. Testers are not the solely responsible or even the primary owner of quality. Quality is a shared responsibility of the whole team. Individuals in an agile team may specialise in a particular role but will take on different roles depending on the context. Testers who are out of ...


7

Your testers deliver the tests scenarios that should be implemented by the developers and some of your developers write more tests than required. Give them a raise! I recommend to review the extra tests and check if they make sense. Encourage all developers to write more tests to put their knowledge into tests. They know implementation details, so they can ...


7

Ideally I would like to write the test based on a file that approximates what my script would be actually processing, rather a much much smaller sample size. If it were me, I would test functional correctness and scale independently. Fault isolation is easier that way. Your code/test/debug cycle can go more quickly too. The thinking here is that ...


7

You're absolutely right to feel that your time in the early stages is best spent understanding the problem. Mapping the use cases and data/control flow of the requirement is one good way of building up that understanding, and in doing so, you are also testing those requirements as you will discover questions that you want to ask, gaps and ambiguities that ...


6

I read two questions: (1) should we document the tester-written unit tests and (2) how should we treat tests that assume implementation details? It's important to distinguish between scaffolding and unit tests. (Please don't get caught up in my terminology; I'm just trying to make a point about some concepts.) Scaffolding is code a developer writes as ...


6

IMHO just writing tests is a Bad idea. If you want people to learn how to be unit testers then fine getting them to write tests for the codebase will get them experience writing tests for the codebase. The will learn how to consume the code base, and not necessarily work on the code iself. If you want them to be actual developers, I would, instead have ...


5

Use your testing skills to help the team define each story more concretely. This shifts your contribution from one of strictly detecting problems to one where also help to prevent them. As stories are being prepared for the next planning meeting, work with the product owner and developers to clarify the boundary of each feature. Use your well-developed ...


5

Testing is a means to an end, not an end in itself. If you are satisfied with the quality of your work using your current development and testing practices, there is no need for additional work. If you are not satisfied with the quality of your work, writing unit tests is one possible path to improvement. I cannot guarantee that writing unit tests will ...


5

Your summaries are fine. Alas, I don't think they'll help you avoid confusion when you talk to other people. If people in a conversation are using the words differently, you'll have to sort out the meanings, and injecting my own summaries never seems to help. Sorting the meanings is always a negotiation. Fortunately, for most conversations it isn't ...


5

Yes. I call them Contract Tests. One easy way to understand them: Start with tests for a specific implementation of the interface. For example, consider ArrayList implements List. You write tests for ArrayList. One test could be this: testEmptyIffZeroSize: list = new ArrayList() assert list.isEmpty() assert_equals 0, list.size() Notice that ...


5

I assume you are asking how to test code that is time-dependent. One strategy is to refactor the code under test so that you control the definition of the current time. For example, in Java, instead of calling System.currentTimeMillis(), you might call a method on a "time provider" interface. The default to implementation of that interface would call ...


4

I think Stacy calls it 'Branching by Abstraction' For legacy code the best approch I've found is to find pinch points in your code where it's easy to insert an interface covering the inputs and outputs. Copy your first implementation, refactor, and then have a regression implementation that runs the old way and the new way and stops dead as soon as any ...


4

Ok, this is going to be a long answer, sorry. You approach is nearly there, but we can test a lot more if we do a little more abstraction. Firstly lets define an interface for your form (view) that will get the values that have been input and set the result value back. public interface IView { string Input1TextBox { get; } string Input2TextBox { ...


4

The objective is to resolve conflicts between components being integrated. Those kind of conflicts cannot be found during unit tests. The example of dishwasher of @user246 is very illustrative here. Type of conflicts you may encounter: A component transmits syntactically wrong or no data. The receiving component cannot operate or crashes ...


4

You can create an Even listener: EventListeners (NUnit 2.4.4) Interface The extension object passed to Install must implement the EventListener interface: public interface EventListener { void RunStarted( string name, int testCount ); void RunFinished( TestResult result ); void RunFinished( Exception exception ); void ...


4

What you're observing is common whenever the job of a method is to change some internal state (like the set of things stored in an internal collection). There are two options: Recognize that the desired results are observable only through subsequent calls to other methods. Add a way to observe the internal state directly. This generally requires making ...


3

You NEED a test to show that the refactoring didn't break anything. I am a big fan of the A B theory based test that @Squirrel described. I am also a big fan of characterization tests from (working w/legacy code) via Michael Feathers. Personally, this is the technique I use in 90% of my work with legacy code (it's a variation of characterization tests). ...


3

No. It's too late for the tests to affect the design, so you can't get the major benefit of TDD. What you can do, however, is to write tests as you work on the code. Say you've got a method that's too long. Write a test of a little piece of it, assuming that little piece had been extracted into a new method. Now extract that method. Or say a bug report ...


3

In the traditional sense of the word a unit test is designed to test the smalled functional unit of software such as s single method or function. Unit tests are intended to provide limited testing of the functional capabilities of a function or method in isolation. Typically, unit tests are written and maintained by developers because they should be used by ...


3

The key question is can you afford for it to go wrong? And the answer to this quite often is dependent on how quickly you can fix the problem if it occurs - debug it until it works in production. While not a nice place to be, for some things that once done, should never need to be revisited you can get away with having no tests. If your business / lives ...


3

We called those the BIST : Built-In Self-Test. The main "customer" from our viewpoint was manufacturing. They needed a suite of tests that they could run to verify that the hardware coming off the end of the line was good. The development team was responsible for implementing the tests, manufacturing was responsible for defining and running the tests.



Only top voted, non community-wiki answers of a minimum length are eligible