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 ...
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 ...
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 ...
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 ...
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 ...
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:
Success in both speed and reliability for ...
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 ...
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 ...
You can create an Even listener:
EventListeners (NUnit 2.4.4)
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 ...
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 ...
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
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.
for most conversations it isn't ...
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 ...
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 ...
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 ...
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 ...
Mutation testing (or mutation analysis or program mutation) is used to
design new software tests and evaluate the quality of existing
software tests. Mutation testing involves modifying a program in small
https://pitest.org/ for java
https://pypi.org/project/mutmut/ for python
Yes, Unit-testing is only software related. No testing the implementation of a dashboard cannot be considered Unit-testing. Unit-tests typically test relatively small programming functions. A dashboard is the result of a lot of programming classes which consist of even more smaller programming methods (a.k.a. functions).
Unit tests are typically automated ...
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:
list = new ArrayList()
assert_equals 0, list.size()
Notice that ...
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 ...
Nose is no longer maintained:
Nose has been in maintenance mode for the past several years and will
likely cease without a new person/team to take over maintainership.
New projects should consider using Nose2, py.test, or just plain
Even though unittest from the Python standard library is a very mature test framework with built-...
Unit test are far superior in detecting root cause of the bug, compared to e2e tests. Maybe I am lucky, but our developers are religious about adding unit tests - because they experienced that it helps them to detect errors sooner, and allow for refactoring.
When e2e test reports a problem, you have to investigate what went wrong. Unit test tells you ...
It starts with explaining developers to take their discipline serious. They should follow the programmers oath.
I will produce, with each release, a quick, sure, and repeatable proof
that every element of the code works as it should.
I like how UncleBob compares developing software to double-book-keeping in accounting and disciplines like hand-washing ...
If there is one thing I like about good test names is that when it fails on a build-server I can understand what is broken just from reading its name. If the name of the test does not describe what it does it means you need to read the test code to see what is going on.
When an automated test fails, I want to understand what I just broke — without
As you suspect, there are no magic bullet answers to your question, but I can offer some suggestions to consider.
Wherever possible, look to code any particular action exactly once and reuse it multiple times.
Whereever possible, drive your tests with a combination of object-oriented and data-driven test code.
Where you can string together a ...
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 (functional ...
I'm not sure whether or not these qualify as "well known", but they certainly qualify as "nasty" (and apply to any kind of application):
Global gobs: heavy reliance on global values for information, making it difficult to tell what modifies which variable where.
Ball of spaghetti: everything is closely related to everything else, and when you change ...
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 ...
Yes you should have scenarios which verify the unit tested business rules.
good unit tests mock and stub the datastore. Acceptance tests make sure it is configured and works correctly.
unit tests usually test logic but don't allow for usability and accessibility
unit tests don't test whether the application works on the vast array of devices ...