9

How the answers are calculated Statements : Simply, these are what you have in the boxes and diamond shapes. You can cover all the statements in the flowchart by writing 1 Test Case that follows the following route 1A-2C-3D-E-4G-5H. Therefore, the Statement Coverage is 1 Branches/Decisions : Decisions that you can take in the process flow diagram (For ...


4

To answer your second question first, defects found in white box testing are the same defects that could be found in black box testing. The main difference is that some defects can be more easily found by white box testing than black box. White box testing can be more than just statement/branch/path coverage. It can also include evaluating application ...


3

Back-end should be tested separately regardless of test results on the front-end. The main reason would be security. It's great that you have tested that front-end can send to back-end only numbers, but what if some person purposely use intercepting tool and forge request send to your back-end and change the number to any other naughty value? This may cause ...


2

When you run white box tests depends on your goal. If your goal is to maximize code coverage then you probably want to measure code coverage, which means you need to run your SUT (system under test) in an environment where you can measure code coverage, e.g. in an IDE or attached to special libraries that collect coverage metrics. If your goal is more ...


2

One of the common ways to unit test the code that uses boto client, aside from "manual" mocking and patching, is to use the moto library which provides a drop-in replacement for the boto client specifically for the use in testing. I don't think you need to set up a virtual inbox, just check that the notification was sent with moto.


2

You have 4 possible decisions/branches: B-C B-D D-E D-A The 2 test cases A-B-D-E-F and A-B-C only cover 3 (1. – 3.) out of 4, which is why it's 75% decision/branch coverage.


2

With your reference to your test case what you have provided is correct but think how the application/function will take the input. It can take only three inputs so when your conditions are split based on the input then we need 5 test cases to execute it. Test Data from your reference: t = -1, 1, 101 s = 99, 101 l = 49, 51 so your test case will be like t=1 ...


2

In addition to Kate and user246's answer. I would like to add that white box testing is normally coded and executed by developers. Yes, white box testing does not have to be automated testing but it is more common for it to be automated. Developers commonly use a unit-testing framework to support their white box testing. Regarding your question: But what ...


1

This is the table showing the values which impact the conditions in your code: Since there are four lines with temperature <0, >100 condition, you can pick different values near both the temperature threshold levels for different tests.


1

Think Boundary Testing based on the conditions shown. The conditions are: t < 0 t > 0 and t < 100 and... s > 100 and l <= 50 s > 100 and l > 50 s < 100 or l > 50 s < 100 and l < 50


1

Is it necessary to consider inputs that the front end blocks when testing the back end? The short answer is YES. The reason the answer is yes is because it is trivial for anyone with a little knowledge to bypass the front-end validation and send invalid data to the back end. It can be done with the tools built in to every browser, not to mention any proxy ...


1

If you're responsible for testing the entire solution then you have to consider all the components which compose that solution. If you are responsible for only back-end testing then you should concentrate on the back-end and do not care of any integrational aspects. In the latter case just leave that headache to the people who are put in charge of ...


1

Unit tests are more closer to the application code where defects hide so easier to design and catch issues on that level compared to black box tests which are many layered away from the issues. On top of other existing good answers, I would like to add a simple unit test code example for reference: testAdd() { int x = 5; int y = -2; int ...


1

Let's start with the basic stuff. Your provided flow chart is simply another representation of example code 1. Every control flow is represented as edge (here line) and connects always two nodes (here statements). In contrast to black-box testing you know the program code that you want to test in white-box testing. In your example you take the code under ...


1

Before doing control flow test, you need to draw a flowchart, then choose a coverage to work with. For statement coverage, you need to find paths (from start to end of flowchart) that go through all statements and the number of these paths is the smallest. In other words, if you run all paths you find out, all statements will be executed and the number of ...


1

Terminology may be not that transparent and some might say that the database - is a dependency, authentication backend - is a dependency (hence, no testing in isolation that is in the "unit test" definition) and think of this kind of tests as "integration"/"functional"/"system". On the other hand, Django and tools around it provide ways for you to use a ...


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