Hot answers tagged unit-tests
19
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 ...
13
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 ...
11
> 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. ...
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 ...
8
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 ...
8
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 ...
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 ...
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
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
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
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 ...
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
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
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
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
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
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.
3
I would recommend that you use the Database unit testing features of Visual Studio 2008 Database Professional aka "Data Dude"
There is a great in-depth blog post about it here, which includes a full step by step walkthrough.
3
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 ...
3
Sorry,i do not share the same opinion
-- finding a "lot" a bugs does NOT make a "great" tester.
finding a lot of "important" bugs does (bugs that matter,make an impact,provide the right contextual informatin matching the mission of testing).
finding a lot of "new" tests to execute makes a great tester
making it easier for the business to take ...
3
Approvaltests.com calls them unit tests, so I'm not going to argue :) Although I'm not sure why you are looking for a hard definition. It's taking the value from unit tests, adding readable output and screenshoting them. Kinda a neat process that could be used for UAT and forces dev's to use TDD. Tools that I would consider similar are Cucumber, jBehave, ...
3
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
