Cada pacote de viagem é avaliado no valor de 40 mil reais. Valor total da premiação, câmeras + viagens: 622.306,04 reais.
Deixe seu passaporte e visto de entrada para os EUA em dia para caso você seja o ganhador, não perder esta viagem de aventura nos parques de Orlando.

Os clientes pessoa jurídica ou física, com idade igual ou superior a 18 anos, domiciliadas/residentes em território nacional, terão direito a 01 (um) número da sorte a cada R$500,00 (quinhentos reais) em aquisições na PMG, por compra, durante o período de vigência da campanha.
Serão emitidos tantos números da sorte quanto forem os múltiplos de R$500,00 (quinhentos reais) adquiridos em produtos PMG, por compra, durante a vigência da promoção. Eventual saldo resultante desse cálculo, que não seja suficiente para completar um múltiplo de R$500,00 (quinhentos reais), será descartado e não poderá ser cumulado com o valor de compras futuras.
O participante ainda terá direito a 01 (um) número da sorte extra para cada R$200,00 (duzentos reais) contabilizados, na mesma compra, em produtos de umas das seguintes marcas:
Os clientes receberão uma via da nota fiscal, constando o nome da promoção comercial, os números da sorte aleatórios a que tem direito, o número do certificado de autorização e o link para consulta do regulamento.
Concorra a cinco motocicletas Honda CG 160cc Start ano de fabricação e modelo 2020, zero quilometro, no valor de 9.080,00 reais cada uma.

A principal função de marketing é produzir e entregar valor para os consumidores, criando uma ponte entre o mercado e os produtos da empresa. É uma ferramenta a ser utilizada pelas as empresas para alcançarem seus objetivos. Os seus principais elementos são: mercado-alvo e segmentação, demanda e oferta, canal de venda e cadeia de suprimento, concorrência e ambiente de marketing.
O setor de marketing teve origem na área de vendas. Com o desenvolvimento e crescimento das empresas, surge a necessidade de se reestruturar, normalmente com uma orientação voltada para o marketing. É muito comum colocar tal área acima ou no mesmo nível de vendas; essa reestruturação é denominada “ciclo das organizações de marketing.” É frequente que ambas as áreas trabalhem juntas visando alcançar os objetivos organizacionais.
Visto isso, é necessário que haja uma organização de marketing para que aconteça uma boa resposta, a partir da necessidade do mercado e para que a empresa seja o mais eficiente possível. Além disso, a empresa consegue, a todo instante, ir se adaptando às transformações constantes do mercado.
Ademais, é essencial que procurem implementar, da melhor maneira possível, a filosofia de marketing, independente da estrutura da área (funcionários, setores específicos). É possível que a empresa possua ótimos funcionários, diversos departamentos especializados e um moderno sistema de atendimento ao cliente. Porém, apesar de toda a estrutura, a burocracia envolvida acaba dificultando o contato do cliente que busca soluções imediatistas e isso faz com que os clientes desta empresa fiquem insatisfeitos. Isso não muda a necessidade das empresas de possuir infraestrutura buscando se prepararem adequadamente para entender o que o cliente deseja.
A organização deve ter como principal objetivo alcançar a satisfação de seus clientes e, para conseguir esse feito, é necessário que desenvolva cargos e tarefas que funcionem, de acordo com suas necessidades. Também é necessário que possua um excelente programa de recrutamento e treinamento de seus funcionários. A filosofia de marketing tem de ser implantada de maneira análoga a um programa de qualidade, um trabalho de paciência e dedicação, para que, gradualmente, seja disseminada a filosofia entre todos os empregados dos diferentes departamentos.
A área de Marketing com planejamento propõe um diferencial na sua empresa, um crescimento da organização e um alcance de mais consumidores e vendas, resultando num maior lucro.
Para maiores resultados, entre em contato com a PUC Júnior Consultoria. Analisamos as ameaças e oportunidades do mercado e determinamos os pontos fortes e fracos da empresa. Isso, certamente, alavancará as vendas e a divulgação dos produtos ou serviços e aumentará a visibilidade da marca ou produto no mercado que está inserido.

Neste espaço, podes rever as últimas entrevistas e os últimos programas mais marcantes que aconteceram na tua rádio! Se ouviste e gostaste, então agora podes também partilhar com os teus amigos pelo facebook, por exemplo... Se não ouviste, é este o espaço indicado para que fiques a saber o que perdeste!
Em destaque estão sempre as entrevistas mais recentes, mas podes consultar todas as disponíveis se carregares no botão "UP NEXT" que se encontra no canto inferior direito de cada player! Depois é só escolheres a que queres ouvir e desfrutar onde quer que estejas!

Fixture: uma pré-condição, dados iniciais fixos em que conhecemos qual será o resultado obtido pela aplicação se os fornecemos como entrada.
Dependendo de como é feito esse teste, principalmente do que é a “AUT”, os testes podem ser classificados como sendo:
Teste de Unidade: a AUT é a menor unidade de software sendo implementada. No caso de Orientação a Objetos, a AUT seria uma classe e testaríamos os seus métodos. Observação: é comum o uso do nome Testes Unitários para se referir aos Testes de Unidade. Eu, particularmente, não gosto desse nome pois parece que haverá apenas um teste.
Teste de Integração: a AUT é um componente de software, ou seja, agrega várias unidades para atingir um objetivo/funcionalidade. Neste caso, estamos testando se a integração entre essas diversas unidades que compõem o componente (ou serviço) está funcionando adequadamente.
Teste de Aceitação: a AUT é a aplicação como um todo. O teste se baseia em usarmos a interface do programa e verificar se as funcionalidades estão corretas. Observação: é comum o uso do nome Teste Funcional justamente por testar as funcionalidades do programa. Não tenho nada contra esse nome, mas gosto mais do nome cunhado por Kent Back. Os testes de aceitação podem ser, também, de vários outros tipos. Pode-se verificar a performance do programa, sua segurança entre outros critérios. Nesses casos é comum o uso do nome Teste Não-Funcional.
É importante observar que os Testes de Unidade devem executar muito rapidamente, pois são testados frequentemente. Por isso, eles não devem usar o banco de dados, rede, etc. Senão, seriam, na verdade, Testes de Integração, não é mesmo! 😉
O nosso foco, neste artigo, são os Testes de Unidade. Vejamos, então, um exemplo de como testar uma classe. Suponha a seguinte unidade de código, a classe Calculadora:
Nós podemos testá-la de várias formas. Uma delas é criar um programa que lê do usuário os dados de entrada, “exercita” o código da classe Calculadora e o usuário verifica por conta própria se os valores estão corretos. Esse código poderia ser assim:
Este tipo de teste é chamado “Teste Manual“. Acho que já deu para perceber que, caso haja alguma alteração na classe, o programador vai ter que executar esse programa cada vez que isso ocorrrer e testar, “na mão”, as várias possibilidades. É comum, nesses casos, termos um script de teste. Por exemplo, uma tabela da seguinte forma:
Imagine a cena: o programador imprime essa tabela, executa o programa para cada uma das linhas e vai “ticando” o que deu certo. Obviamente, conforme o número de testes vai aumentando, essa prática se torna inviável (além de ser altamente prejudicial para a saúde mental da pessoa – não, não estou brincando!).
Um programador mais experiente automatizaria essa tarefa! Ele poderia, por exemplo, criar o seguinte código para testar a classe Calculadora:
Com certeza, isso vai poupar muito tempo do programador. Basta ele executar o programa e obter um relatório do que deu errado. O problema é verificar esse relatório toda vez… Veja, um sistema completo não é feito de apenas uma classe. Podem haver milhares delas! Imagine ele ter que executar vários programas de testes e olhar cada um dos relatórios. Sem dúvidas, uma tarefa que, também, vai se tornando inviável!
Além do problema apontado no parágrafo anterior, você deve ter percebido que o programa ficou um tanto quanto complexo e com necessidade de algumas condições para testes específicos (caso do NaN). Esse cenário torna-o de difícil leitura e, consequentemente, de difícil manutenção. Imagine que a classe Calculadora agora tenha um método chamado getPotenciacao(). Para alterar o teste, teríamos que modificar a fixture, acrescentar mais algumas linhas de testes usando o índice correto do vetor. Sem dúvidas, um caminho nada agradável…
É aí que entra o JUnit. Ele é um framework que nos ajuda a criarmos códigos para Testes de Unidade Automatizados de forma que eles não fiquem essa bagunça toda. Além disso, ele emite relatórios de resultados bem fáceis de se visualizar, além das IDEs mais usadas já terem integração, o que facilita a verificação de erros.
Criar testes com o JUnit é muito fácil: basta criar uma classe normalmente e anotar os métodos com @Test. Dentro de cada método de teste, devemos usar os comando assert... para verificar se o resultado obtido está correto.
Não vou entrar em detalhes de como configurar o JUnit sem usar uma IDE. Vamos ver um exemplo usando o NetBeans. Para isso, basta ir no menu “Arquivo” > “Novo Arquivo” e irá aparecer a seguinte tela:
Nesse caso, já selecionei a Categoria “Testes de Unidade” e Tipo de Arquivo “Teste JUnit”. Basta clicar no botão “Próximo >” que a seguinte tela irá aparecer:
Nela, você irá entrar com o nome da classe de testes (chamei de CalculadoraTest) e o pacote onde ela irá estar (normalmente, no mesmo pacote da classe que você quer testar). No meu caso, eu também deselecionei todos os checkboxes que aparecem. Aconselho que faça isso, pelo menos enquanto está aprendendo a criar suas classes de teste.
Um detalhe sobre o nome da classe de teste: seguindo a convenção usada nas versões anteriores do JUnit, a classe de teste deve ser o nome da classe sendo testada seguida da palavra Test. Como estamos testando a classe Calculadora, o nome da classe que vai testá-la será CalculadoraTest.
Agora, vamos acrescentar um método para testar alguma funcionalidade da classe Calculadora. Dica: use um método para testar cada uma das funcionalidades que se quer testar separadamente. Vamos, por exemplo, testar o método getSoma().
Veja que criei um método chamado testSomaDeveRetornar0QuandoPassamosZeroEZero() anotado com @Test. Eu costumo usar a palavra test na frente de cada método pois era uma convenção necessária nas versões anteriores do JUnit. Mas, fique à vontade para colocar o nome que quiser. Também uso um nome bem descritivo do que o teste faz. Dentro dele, eu preparei a fixture (valores n1 e n2), “exercitei” o código da calculadora e verifiquei usando o assertEquals, que é um método do JUnit para verificar se dois valores são iguais. Nele, passamos o valorEsperado como primeiro parâmetro e o valorObtido como segundo.
No caso de comparação de doubles, é necessário passar um valor que será a máxima diferença que os dois parâmetros anteriores devem ter entre eles para que ainda sejam considerados iguais. Dessa forma, criei uma constante que será usada toda vez que precisarmos fazer a verificação de igualdade entre dois valores double.
Para ver o JUnit em ação, usamos o menu “Executar” > “Testar Arquivo”. O NetBeans irá passar nossa classe de teste para o JUnit que irá criar um relatório de testes. Esse relatório é apresentado pela IDE da seguinte forma:
Já a cor vermelha nos dá um feedback natural de que algo deu errado. E, o JUnit nos avisa que, no método testSomaDeveRetornar10QuandoPassamosDezEZero(), ele esperava 0.0, mas o valor recebido foi 10.0. Ou seja, ou a classe Calculadora está errada, ou nosso teste está errado. Se você prestou atenção, viu que eu copiei e colei o código anterior, fiz algumas modificações, mas esqueci de atualizar o valorEsperado. Vamos corrigir isso:
Bom, agora que você pegou o jeito, é só ir escrevendo os testes, um a um. Temos alguma repetição de código (falarei sobre isso daqui a pouco), mas o JUnit tornou os testes bem mais fáceis de serem lidos do que aquele outro código que fizemos para automatizar os testes. Além disso, o relatório é bem melhor! Veja ele completo: 😉
Uma coisa que pode estar te incomodando é a questão da divisão por zero. Estamos esperando valores do tipo NaN e Infinity. E, se mudarmos nosso método getDivisao() para verificar se o n2 é zero e gerar uma exceção? Vamos fazer isso:
Mas, agora, temos um “problema”: como testamos um código que gera exceções? Melhor dizendo, como testamos um código onde sabemos que exceções devem acontecer? Simples:
Notou que podemos passar um expected = ClasseDaExcecao.class como parâmetro da anotação @Test? Isso faz com que o JUnit não dê erro caso a exceção seja gerada e, mais ainda, aponte como sendo uma falha caso ela não seja gerada!!!
Nesse exemplo que passei, usamos o método bottom-up, ou seja, criamos primeiro a classe Calculadora para depois criarmos testes para ela. Eu, particularmente, prefiro uma abordagem top-down onde primeiro escrevemos os testes e depois o código para fazer ele passar.
Obviamente, você não conseguirá escrever um monte de testes para um código que não existe. Por isso, a abordagem top-down deve ser feita em pequenos passos, um teste por vez. Quando fazemos isso, estamos usando um método conhecido como Test Driven Development (Desenvolvimento Orientado por Testes). Como essa técnica conduz a códigos mais modulares, ela também é chamada de Test First Design (Projeto baseado Primeiro em Testes). Nota: traduções livres! 😉
Só um detalhe: o TDD envolve mais algumas práticas como, por exemplo, criar o código mais simples que faça o teste passar, baby steps, entre outras. Se quiser ver isso em ação, frequente algum Coding Dojo! 😉
Vejamos nosso caso: para podermos criar um objeto da classe Calculadora precisamos dos números que ele vai calcular. Talvez, se tivéssemos feito um teste primeiro, onde a gente escolhe como seria nossa classe ideal, teríamos feito um código assim:
Note que, agora, a criação do objeto não depende mais das entradas. Isso permite que a gente possa colocar a criação do objeto em outro lugar, evitando que esse código se repita a cada teste. No entanto, se criarmos o objeto no construtor, ele será o mesmo para cada teste, o que nem sempre é desejável. Existe um princípio de que os Testes de Unidade devem ser independentes entre si. Ou seja, gostaríamos que, a cada método de teste que for executado, um objeto diferente seja criado. Como fazer isso?