Tag Info

Hot answers tagged

23

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 ...


22

Yes, it is. Because the unit tests are not only for the current version of the code. They are especially for all future versions and if somebody changes the code and does not know what s/he did, the test can fail and tell him that he did something wrong. So you can't say that this will never happen. Also unit tests do not only test code, they are ...


17

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 ...


16

> 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. ...


16

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 ...


11

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 ...


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

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 ...


10

IMO you should go ahead and write the unit tests for passing statements before doing any refactoring. The reason is because you want to be in a known state before making changes.


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 ...


8

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 ...


8

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 ...


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

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

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 ...


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

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

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

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 ...


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 ...


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

There are two (actually both are very similar) techniques in order to reveal the tests which tend to be "false/positive" ones – Error Seeding and Mutation Testing. The both principles are based on introducing the errors in the application's program code, mainly in the places where it will have the most dramatical effect for application. It can be for ...


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

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 ...


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

Couple of ideas to evaluate application architecture and decide Test Approach Testing different layers My approach to get started is evaluate (Web Service, Database Testing, UI Testing, Security and Cloud specific testing on infrastructure/scalability/performance) If it is SOA-based implementation, you probably would have a service layer exposed which ...


4

Absolutely you should write unit tests. There's no guarantee that your small project isn't going to get added to at some later date - or that the next version of your operating system won't deprecate the calls your project is making to something. Or any of innumerable other strange things won't happen. It's not that uncommon for someone's prototype to become ...


4

TL;DR answer Yes, unit tests are worthwhile even on small projects. Full answer For many years I was under the misapprehension that I didn't have enough time to write unit tests for my code. When I did write tests, they were bloated, heavy things which only encouraged me to think that I should only ever write unit tests when I knew they were needed. ...



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