Tag Info

Hot answers tagged

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


21

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


15

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


14

> 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

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

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


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

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

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


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

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


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

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

If you are curious about the tradeoffs around mock objects, there are entire websites and books devoted to the subject. I will restrict my answer to the specific problem you described. I never replace a real system with a mock system unless the real system does not meet my needs; a mock system requires time to write and maintain, and when a test fails, you ...


4

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


4

Writing and maintaining automated tests is a big investment and it is ok to start slowly It is expensive to write and maintain automated tests. If the tests are written in an ineffective way, the investment may not pay off. Similarly, if the tests require a great deal of maintenance, either because of how the tests are written or because the interfaces ...


4

To answer question 1: Yes, I'd separate the unit test code from the integration test code. They're logically different, are probably built differently, and you're planning on running them differently. I'd also name them differently too for extra clarity. For example our unit tests are in a ut_* directory and named ut_classname, so I'd put the integration ...


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



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