Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
35

Is it still needed to write acceptance tests that target verifying those business rules implementation? Yes, it is absolutely necessary. Your unit tests cover the business rules in isolation. Your acceptance tests verify that the application properly implements those business rules from a customer perspective. There are many cases where the unit tests ...


26

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


26

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


19

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


19

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


14

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


13

The short answer - Usually they don't. Developers write unit tests and ideally run them every time the software builds. The longer version - Unit tests are intended to test a single unit of code. This means that they are not testing through the application user interface, but are running directly against the single unit they are testing and using stub/mock ...


13

A key strategy for me is to convince the business of what needs to be tested where, otherwise... they'll end up directing testing everything through the UI... So the two key main points I am making to my business are the need for test automation that performs well in terms of two key factors: Speed Reliability Success in both speed and reliability for ...


12

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


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.


10

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


10

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


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


9

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


9

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


9

I am definitely using the test pyramid as one of my 'guidance' tools. I frequently combine it with the 4 Agile Testing quadrants in talks and presentations.                                As Niels says this ...


8

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 TestStarted(TestName ...


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


8

The TDD cycle is more a development cycle for a developer, to quote James Shore, The Art of Agile, Test-Driven Development chapter: Programmers new to TDD are often surprised at how small each increment can be. Although you might think that only beginners need to work in small steps, my experience is the reverse: the more TDD experience you have, ...


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

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


7

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


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

Full disclosure: we rely heavily on FitNesse, run many hours worth of FitNesse tests daily in our CI buildbot daily, and I personally wrote both FitNesse tests (using Fit wiki format in browser) and WebDriver tests in Python. FitNesse is for end-to-end testing (browser automation) and Selenium/WebDriver in much superior replacement, especially if you ...


7

Estimate working load, how many test cases are there to be migrated from UI tests? Estimate how much time you can spare in each sprint and discuss with your team leader and your fellow members regarding you want to spare some time in each sprint to work on test case migration. Prioritize automated UI tests, there is a chance a portion of them are no longer ...


6

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


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


6

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


6

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


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