Questões de Concurso Público PRODEB 2018 para Analista de TIC I - Construção de Software
Foram encontradas 50 questões
A definição de uma variável é uma das etapas principais para elaboração de um programa, que pode ser compreendida como uma reserva de um espaço na memória do computador para armazenar informações. Em relação aos tipos de variáveis, informe se é verdadeiro (V) ou falso (F) o que se afirma a seguir e assinale a alternativa que apresenta a sequência correta.
( ) Variável do tipo caractere serve para armazenar um único caractere podendo ser letra ou símbolo.
( ) Variável do tipo inteiro é utilizada para armazenar valores numéricos, podendo ser positivos e negativos e, também, valores com ponto decimal.
( ) Variável do tipo numérico real armazena valores reais, inclusive valores com ponto decimal, podendo ser positivos e negativos.
Set the Table
When you begin writing tests, you will discover a common pattern:
1. Create some objects
2. Stimulate them
3. Check the results
While the stimulation and checking steps are unique test-to-test, the creation step is often familiar. I have a 2 and 3. If I add them, I expect 5. If I subtract them, I expect – 1, if I multiply them, I expect 6. The stimulation and expected results are unique, the 2 and the 3 don’t change.
If this pattern repeats at different scales (and it does), then we’re faced with the question of how often do we want to create new objects. Looking back at our initial set of constraints, two constraints come into conflict:
· Performance—we would like our tests to run as quickly as possible
· Isolation—we would the success or failure of one test to be irrelevant to other tests
For performance sake, assuming creating the objects (we’ll call them collectively the “fixture”) is expensive, we would like to create them once and then run lots of tests.
But sharing objects between tests creates the possibility of test coupling. Test coupling can have an obvious nasty effect, where breaking one test causes the next ten to fail even though the code is correct. Test coupling can have a subtle really nasty effect, where the order of tests matters. If I run A before B, they both work, but if I run B before A, then A fails. Worse, the code exercised by B is wrong, but because A ran first, the test passes.
Kent Beck – Test-Driven Development By Example. Addison-Wesley Professional; Edição: 1. Novembro, 2002. Page 82.
Set the Table
When you begin writing tests, you will discover a common pattern:
1. Create some objects
2. Stimulate them
3. Check the results
While the stimulation and checking steps are unique test-to-test, the creation step is often familiar. I have a 2 and 3. If I add them, I expect 5. If I subtract them, I expect – 1, if I multiply them, I expect 6. The stimulation and expected results are unique, the 2 and the 3 don’t change.
If this pattern repeats at different scales (and it does), then we’re faced with the question of how often do we want to create new objects. Looking back at our initial set of constraints, two constraints come into conflict:
· Performance—we would like our tests to run as quickly as possible
· Isolation—we would the success or failure of one test to be irrelevant to other tests
For performance sake, assuming creating the objects (we’ll call them collectively the “fixture”) is expensive, we would like to create them once and then run lots of tests.
But sharing objects between tests creates the possibility of test coupling. Test coupling can have an obvious nasty effect, where breaking one test causes the next ten to fail even though the code is correct. Test coupling can have a subtle really nasty effect, where the order of tests matters. If I run A before B, they both work, but if I run B before A, then A fails. Worse, the code exercised by B is wrong, but because A ran first, the test passes.
Kent Beck – Test-Driven Development By Example. Addison-Wesley Professional; Edição: 1. Novembro, 2002. Page 82.
Conheça nossos planos