Waitforexist

Comunidade AutoHotkey.
Aguarde a existência de um arquivo e inicie-o.
Melhor resposta magicool 01 abril 2013 - 06:51 AM.
Isso não funcionaria quando o arquivo não existe. A primeira versão funciona bem por enquanto. Obrigado pela ajuda!
magicool 27 mar 2013.
Esse script deve verificar a cada n segundos se o arquivo "test. exe" existir em uma pasta e quando o arquivo estiver lá, iniciá-lo.
Esse script aguarda até que o arquivo exista e, em seguida, lança-o. O problema é que ele será lançado a cada 1 segundo de novo e de novo. O que eu gostaria de fazer é: esperar pelo arquivo, iniciá-lo uma vez, esperar que o arquivo desapareça, esperar o arquivo, iniciá-lo. e assim por diante.
Você pode ajudar por favor?
faqbot 27 de março de 2013.
Magicool 29 de março de 2013.
Me desculpe por isso. Eu terei mais cuidado.
Como sugerido, substituí o Loop pelo SetTimer:
mas ainda lança o programa a cada segundo. Como fazer o lançamento apenas uma vez, espere o arquivo desaparecer e depois que ele desapareça começa tudo de novo?
faqbot 29 de março de 2013.
Magicool 29 de março de 2013.
Grandes sugestões. Eu acho que funciona. Você acha que esse roteiro pode ser melhorado?
JadeDragon 29 de março de 2013.
Melhor resposta magicool 01 Apr 2013.
Isso não funcionaria quando o arquivo não existe. A primeira versão funciona bem por enquanto. Obrigado pela ajuda!

Waitforexist
Eu queria saber se existe um método no PowerShell para obtê-lo.
continuamente verifique se existe um arquivo e não progrida até encontrá-lo.
c: \ flag. txt NÃO EXISTE.
Aguarde 10 segundos.
De modo que o & lt; próximo comando & gt; A seção é executada apenas quando encontra o arquivo c: \ flag. txt.
Isso é possível?
Claro que há uma maneira de fazer isso:
Não há lugar como 127.0.0.1.
Marcado como Resposta Zoe. Ohara quinta-feira, 26 de junho de 2014 10:30.
Todas as respostas.
Claro que há uma maneira de fazer isso:
Não há lugar como 127.0.0.1.
Marcado como Resposta Zoe. Ohara quinta-feira, 26 de junho de 2014 10:30.
Eu duvido que teria sido muito útil de qualquer maneira. O requisito era.
& quot; verifique se existe um arquivo e não progrida até encontrá-lo & quot;
então o bloqueio é exatamente o que é chamado. Colocá-lo em um trabalho em segundo plano provavelmente só vai trocar a verificação do status do arquivo para verificar o status do trabalho.
Na verdade mfc, eu concordo e discordo de você: chamadas Synchroneous que tomam o seu tempo têm o seu lugar. Dormir um tópico em um script de segundo plano que não tenha uma interface do usuário também é ok. Depois, há o fato de que a técnica para bloquear um thread pode ser usada em um trabalho sem afetar o console da interface do usuário.
Como o OP pedia uma técnica específica, respondi exatamente isso.
Por outro lado: Concordo plenamente que bloquear uma sessão de usuário interativa por um tempo prolongado, esperando que algo aconteça é, na maioria dos casos, uma Idéia Ruim.
Não há lugar como 127.0.0.1.
Eu duvido que teria sido muito útil de qualquer maneira. O requisito era.
& quot; verifique se existe um arquivo e não progrida até encontrá-lo & quot;
então o bloqueio é exatamente o que é chamado. Colocá-lo em um trabalho em segundo plano provavelmente só vai trocar a verificação do status do arquivo para verificar o status do trabalho.
Meu post foi muito útil, de fato.
Bloquear qualquer instância de um aplicativo (PowerShell nesse caso) é quase sempre uma decisão muito ruim (*) porque bloqueia a interface do usuário.
Você entende que uma interface do usuário, quando bloqueada, não pode processar nenhum outro comando do usuário, apenas porque a interface do usuário está bloqueada?
(Tudo bem, Ctrl & # 43; Break pode interromper o processo e encerrar a sessão do PowerShell também!)
Sua argumentação é apropriada para um não programador.
Imagine a situação: você, o usuário, tem um computador poderoso em suas pontas do dedo, com a última geração do servidor MS, que está executando o seu script PS inteligente que está bloqueando (quantas horas para?) Sua instância do PS. Nesse caso, você não precisa de um computador poderoso, o que você precisa é de um script do PowerShell melhor.
Não ouviu falar de Star-Job?
Passe algum tempo lendo sobre isso, vale a pena a leitura.
(Tudo bem, seu amigo mvp parece nunca ter ouvido falar disso, quando eu olho para o código de porcaria que ele fez usando Star-Job em outro tópico.)
A solução é muito simples: comece um trabalho para esperar o que tiver que ser esperado; em seguida, continue usando a instância do PS normalmente e verifique uma vez ou outra se o trabalho estiver concluído (ou use outro mecanismo de sincronização).
Bloquear a interface do usuário é, desde sempre, não inteligente.
(*) exceto situações muito específicas; Felizmente, os computadores atuais são multitarefa preventivamente.
Eu entendo que bloqueia a interface do usuário, mas não temos qualquer indicação na pergunta que isso vai ser usado em uma sessão interativa ou que o OP não sabe sobre trabalhos em segundo plano. Se for necessário monitorar / esperar por um longo período de tempo, ele pode estar sendo implementado como tarefa ou trabalho agendado, ou até mesmo como um trabalho persistente. Não importa qual seja o ambiente de sessão, será necessária alguma solução para implementar esse comportamento de bloqueio para atender aos requisitos declarados, e a solução publicada o fará.
A suposição é que o OP não é inteligente o suficiente para descobrir ou ter experiência suficiente para saber que o que eles estão pedindo irá bloquear sua sessão interativa enquanto aguarda o arquivo. Eu não vejo nada na questão para justificar essa suposição.
Se for necessário esperar um tempo arbitrariamente longo, um evento registrado permanente pode ser uma solução melhor que o loop de tempo.

Teste de loja virtual automatizado com o WebdriverIO.
Recentemente, migramos nosso website para um novo ambiente. Enquanto participamos, pensamos que poderíamos complementar nosso teste de tempo de funcionamento simples com alguns testes automatizados de loja on-line, para que pudéssemos dormir à noite sabendo que nosso site está OK. Implementamos alguns testes com o WebdriverIO e pensamos em compartilhar o procedimento, caso você esteja procurando um guia rápido. Todo o script de teste está disponível para download aqui.
Nosso cenário de teste.
Quando alguém compra Ghostlab em nosso site, eles têm que fazer várias coisas: adicionar o Ghostlab ao carrinho, ir à página do carrinho, clicar no botão de checkout, fornecer todas as informações necessárias no formulário de pagamento, pagar pelo pedido e finalmente espere receber suas informações de licença via E-mail. E esse é exatamente o procedimento que queremos incluir em um teste automatizado.
Etapas do teste automatizado Vá para a página de destino do Ghostlab Clique & # 8220; Compre & # 8221; link para chegar à página de produto WooCommerce Adicione Ghostlab ao carrinho Clique em & # 8220; Carrinho de compras & # 8221; para ver o conteúdo do carrinho Prosseguir para finalizar o pedido Formulário de pagamento completo Pagar & # 8211; nós faremos isso com um truque Na conclusão do pedido, receba E-mail com chave de licença.
Configure o projeto WebdriverIO.
Antes de começar, você precisa configurar um projeto WebdriverIO. É muito fácil, basta seguir o guia WebdriverIO. O que você está fazendo é basicamente:
configurar o seu servidor de download de diretório de projeto e driver & # 8211; Certifique-se de iniciar o servidor após o download. instale o webbdriverio via npm.
Depois de configurar, vamos criar diretamente um test runner para o nosso projeto. Basta seguir as instruções sobre como preencher a caixa de diálogo de configuração do testrunner (guia WebdriverIO, "Vamos ser sérios" & # 8221;). Observe que, a partir de hoje (13 de janeiro de 2017), há uma etapa de configuração adicional na caixa de diálogo que não está descrita no guia & # 8211; Acabei de selecionar o valor padrão.
Estou assumindo que agora você tem seu diretório de teste / especificações. Agora crie um arquivo JavaScript que permita escrever seu teste. Você deve acabar com uma configuração comparável à da imagem abaixo.
Existem muitas ferramentas para criar testes automatizados. Quando montamos nossos testes, procuramos algo poderoso, bem documentado, fácil de configurar e disponível localmente (ou seja, sem SaaS). Nós demos várias ferramentas rápidas, e o WebdriverIO nos convenceu porque o tempo para o seu primeiro hello world é realmente curto, e está muito bem documentado.
Agora, para as etapas reais do teste, vamos apenas observar um pequeno conjunto de recursos da API Webdriver & # 8211; para a referência completa, consulte Documentos da API do WebdriverIO.
1: Navegue até a página de destino, siga para a página do produto WooCommerce, adicione Ghostlab ao carrinho.
Queremos começar a partir da nossa página de destino do produto, por isso precisamos apontar o navegador para esse local.
Nesta página, há um botão Comprar. Esperávamos que os visitantes que desejam comprar o Ghostlab cliquem nele e acessem a página do produto WooCommerce. Depois de clicar no botão, precisamos esperar que a página do produto WooCommerce seja carregada antes que possamos executar nossas ações adicionais. Portanto, estamos aguardando pela presença de um elemento que não estava na página de destino, mas que está na página do produto WooCommerce, ou seja, o & # 8220; Adicionar ao carrinho & # 8221; botão.
A função click e waitForExist espera um seletor como primeiro argumento. Um seletor é usado para especificar o elemento em questão & # 8211; o que queremos clicar, ou o que estamos esperando para estar presente.
Estamos especificando um tempo limite de 5000 milissegundos para waitForExist & # 8211; caso a página não seja carregada dentro desse prazo, o teste falhará. Portanto, certifique-se de especificar um tempo limite suficiente para que sua página seja carregada.
Existe uma grande variedade de seletores possíveis, encontramos o texto do link (& # 8216; = Buy & # 8217 ;, nos elementos âncora) e os seletores CSS fáceis de serem manipulados. Obviamente, quais seletores são mais adequados para você, dependendo do conteúdo da sua página. Assim que você começar a usar seletores, esteja ciente de que as alterações na sua página podem interromper seu teste. Por exemplo, se tivéssemos de alterar o texto do botão comprar para o & # 8220; Obter um agora & # 8221 ;, o teste não funcionaria mais. Consulte o Guia do desenvolvedor para obter uma referência completa dos seletores disponíveis.
Assim que a página do produto WooCommerce for carregada, haverá um elemento para adicionar o produto ao carrinho, e nossa execução de teste continuará. Em seguida, queremos adicionar 1x Ghostlab ao carrinho pressionando o botão. Quando isso for feito, a página mostrará uma mensagem de confirmação de que a adicionamos ao carrinho & # 8211; e haverá um link que nos leva ao nosso carrinho de compras. Então, esperamos que a confirmação apareça e siga o link do carrinho.
2: insira o código do cupom para que não tenhamos que fornecer informações de pagamento, continue com o checkout.
Assim que o carrinho é exibido, inserimos um código de cupom que preparamos para o teste que nos dá 100% de desconto. Isso significa que nosso pedido totaliza 0 $ e podemos realizar o checkout sem inserir informações de pagamento. Detectamos se o carrinho foi carregado verificando a presença do campo de código de cupom. Em seguida, esperamos pela mensagem de confirmação que o WooCommerce escreve na página para mostrar que o código foi aplicado e verifique se ele foi aplicado com sucesso examinando o conteúdo da mensagem.
Depois que o código do cupom for aplicado, acessamos o formulário de check-out clicando no link de check-out. Detectamos a carga do formulário de check-out verificando a presença do botão de pedido de lugar & # 8211; que vamos usar no final para realmente fazer o nosso pedido.
3: formulário de pagamento completo.
Agora podemos preencher o formulário de check-out. Nós armazenamos os seletores de campo e os valores associados em uma matriz separada sobre a qual podemos iterar & # 8211; Claro, você também pode resolver isso de forma diferente. Um campo que temos que tratar especialmente é o seletor de país & # 8211; isso não é um simples select, mas um componente de seleção aprimorado por JavaScript onde você pode procurar por valores e, em seguida, selecioná-los clicando neles. Não podemos simplesmente definir o valor como um campo de entrada regular, portanto, precisamos executar o padrão de seleção de pesquisa por clique que um usuário real usaria.
Estamos usando a função myWait. Isso simplesmente fará com que o teste espere por um número especificado de milissegundos, usando a função waitUntil em combinação com algum tempo de matemática. Nós o usamos na caixa de seleção JavaScript para garantir que a página tenha tido tempo para primeiro renderizar a caixa de pesquisa e filtrar os resultados. Mais tarde, usaremos a função myWait antes de tentar buscar o e-mail da licença.
4: Coloque a ordem, verifique a confirmação do pedido, extraia o número do pedido.
Agora que o formulário está completamente preenchido, podemos fazer o pedido. Para isso, basta clicar no botão de ordem de lugar. Depois que o pedido for processado, veremos uma página de confirmação. Verificamos que chegamos a ele aguardando a nota de agradecimento e examinando o conteúdo da mensagem. Além disso, extraímos o número do pedido atribuído ao nosso pedido pelo sistema. Precisamos disso para verificar se recebemos o e-mail da licença.
5: Verifique se o email da licença foi enviado.
Na colocação do pedido, nosso back-end deve ter gerado uma chave de licença para o Ghostlab e enviado para o endereço de e-mail que fornecemos no formulário de check-out. Para concluir o teste, precisamos ver se esse email foi realmente entregue. Para isso, usamos um pacote imap de nó para se conectar à conta de e-mail que fornecemos na compra. Antes de tentarmos buscar o e-mail, esperamos por 30 segundos, caso contrário, ele pode não ter sido entregue ainda.
Por padrão, o mocha (que estamos usando em nosso exemplo) tem um tempo limite de 10s & # 8211; então, quando esperaríamos por 30s, isso falharia, pois o tempo limite global se aplicaria após 10s. Você pode aumentar o timeout do mocha nas opções do mocha (mochaOpts. timeout), isso pode ser encontrado no arquivo wdio. conf. js, que é criado automaticamente para o seu projeto.
Sabemos que o texto do Assunto desse e-mail de licença é único & # 8211; é algum texto estático combinado com o número do pedido (que é a parte exclusiva). Assim, podemos simplesmente procurar uma mensagem com o assunto esperado e ficaremos satisfeitos se o número de mensagens retornadas pela pesquisa for exatamente 1. É claro que poderíamos examinar o conteúdo do e-mail da licença, talvez até tentar ativar o produto de software com a licença & # 8211; mas nós deixaremos isso por algum outro tempo.
Note que a chamada para imap. connect () é assíncrona & # 8211; Então, como podemos "# 8220; notificar & # 8221; nosso teste que busca por e-mail foi bem sucedido? Usamos a função waitUntil e passamos uma função que retorna uma variável. Na manipulação de e-mail, definimos a variável como true se buscamos o e-mail com sucesso.
Todo o script de teste está disponível para download aqui.

Cucumber. js e Meteor - O porquê e como dele.
Há muito tempo, em uma galáxia muito distante, havia um jovem programador começando sua carreira de programador profissional. Se eu tivesse acesso a uma Tardis, eu voltaria e diria àquele jovem programador (eu, se isso não fosse óbvio) as coisas mais importantes na programação são 1) Aprendizado Contínuo e 2) Teste. Lembro-me de ouvir sobre o conceito de testar e pensar 'Que desperdício de tempo, escrevo código extra para testar o código normal que escrevo? Por que todo o trabalho duplo? Não ficou muito melhor depois que eu encontrei meu segundo aplicativo com uma suíte de testes e fiz refatoração importante e ele quebrou 90% da suíte de testes - testes frágeis podem ser brutais.
* ATUALIZAÇÃO * Está um pouco desatualizado, não deixe de conferir este post para algo mais atualizado: mhurwi / a-basic-cucumber-meteor-tutorial /.
Então, por que testar? Existem muitos motivos pelos quais você deseja testar, mas aqui estão os dois principais da perspectiva dos desenvolvedores:
Você quer evitar qualquer regressão na sua base de código - ou seja, não permitir que bugs óbvios surjam. Você quer melhorar o design do seu código pensando nos resultados primeiro - por exemplo, escrever um código claro e em bom funcionamento.
É claro que essas duas razões seguem facilmente outros ideais, como maior confiança na refatoração de código, testes fornecem documentação de código adicional e a cobertura de teste facilita a participação de colegas de equipe e ajuda a permitir o crescimento e o dimensionamento da equipe.
Digite pepino, estágio à esquerda.
Talvez você tenha ouvido falar desse teste de pepino, talvez não? A ideia por trás do pepino é que ele começa com o inglês simples e estruturado, para que as partes interessadas não desenvolvedoras possam se envolver facilmente com a criação do conjunto de testes. Eles definem um recurso e explicam qual é o valor do negócio. Não tome minha palavra, vá ler sobre o porquê da pilha.
A essência é que cada recurso deve se resumir a um desses três objetivos finais:
Antes de escrevermos nossa primeira definição de recurso, vamos instalar o pepino: meteor add xolvio: cucumber. Isso adicionará xolvio: webdriver, velocity: core e velocity: html-reporter ao aplicativo para que possamos executar nossos testes.
Agora podemos dar uma rápida olhada em um exemplo de como descrever um recurso em um arquivo de recurso, vamos chamá-lo de login. feature.
Provar sua identidade e trabalhar com dados armazenados de forma personalizada é uma maneira de aumentar a confiança e, portanto, a receita da empresa. Ainda não está rastreando? Vá ler o popping porque o link da pilha acima novamente, entra em detalhes. A razão por que é importante descrever o recurso dessa maneira é que ele dá ao desenvolvedor uma ideia de por que algo é importante e, portanto, pode mudar a forma como ele é implementado. Esta parte do pepino é puramente para documentação, a propósito, isso não é executado através do mecanismo regex de pepino.
Cena dois, cenários.
Pepino é baseado em uma técnica chamada Behavior Driven Development, que é um conjunto de testes processados ​​para nos ajudar a entender o comportamento envolvido em nossos testes. Para nosso teste de aceitação, queremos usar as etapas que usam 'Dado, Quando e Depois' como as frases iniciais para cada teste. Não sei o que quero dizer, vá ler mais sobre o BDD.
Depois de ter o recurso descrito, é importante entender que cada recurso contém várias coisas que queremos testar. Por exemplo, nosso recurso define a capacidade de login e logout, de modo que fornece dois cenários logo de cara. Os cenários óbvios são conseguir fazer login e logout. Mas o que o usuário deve ver quando tiver uma tentativa de login inválida? Agora começamos a fazer testes negativos e positivos, ou seja, testando o que deveria e não deveria funcionar.
Então, vamos construir alguns cenários de pepino:
Agora, uma vez que isso é executado por velocidade, devemos ver algumas informações de pepino cuspidas nos logs:
Basta copiar e colar essas etapas em um arquivo de definição de etapas. Eu gosto de manter os arquivos de definição de etapa nomeados da mesma forma, então vamos fazer um loginSteps. js que se parece com isso:
As principais conclusões do arquivo acima são algumas: estamos usando o webdriver. io quando chamamos helper. world. browser, podemos encadear as ações umas das outras, precisamos esperar que os elementos existam e / ou ficar visíveis para o navegador, porque pepino vai passar muito rápido às vezes, e precisamos ter certeza de que chamamos o retorno de chamada quando terminarmos.
Ah, emptor de advertência.
O que é esse bit de fundo? Isso é um especial antes do bloco que é executado antes de todos os cenários neste arquivo. A razão pela qual nós temos isso aqui é porque a versão atual do PhantomJS usa um jarro de cookie compartilhado, isso normalmente é bom para um navegador da Web, o que nos deixa coisas como se você estivesse logado se o seu teste entrasse em você. sair antes de cada teste para garantir que começamos a limpar cada vez.
Há um bit justo acontecendo no arquivo acima, e como esse artigo já é longo, deixarei como um exercício para o leitor examinar a API webdriver. io para descobrir algumas das chamadas que estou fazendo. Vou dar-lhe uma dica quando se trata de formulários, certifique-se de usar submitForm ('# formId') em vez de tentar clicar ('. Submit-button') - webdriver não parece enviar o formulário em si quando você acabou Clique no botão.
Mas de onde vêm os dados do usuário?
Tantas perguntas! Eu garoto, eu garoto Eu decidi carregar os dados usando um arquivo de velocidade. Você pode colocar um arquivo em qualquer lugar da pasta de teste e certificar-se de que ele termine com fixture. js ou fixture. coffee e ele será executado no espelho de velocidade na inicialização. Aqui está o que a versão que escrevi para telescópio se parece com:
Isso parece ótimo, mas ainda não estou convencido.
Então, descrevemos alguns dos benefícios acima para testes em geral, mas acho que a melhor maneira de escrever um teste de pepino é pensar como o usuário faz. Essencialmente, estamos testando a experiência do usuário para garantir que ela esteja correta, e não apenas para entender códigos ou cálculos, como acontece com um teste de unidade. Considere isso, como fui adicionar os testes acima ao Telescope, descobri que não consegui passar o teste de informações de login incorreto porque nenhum erro é mostrado ao usuário quando o clique 'faz login' com informações incorretas. Essa é uma má experiência do usuário! Acontece que é um bug no pacote useraccounts.
A pior coisa que você poderia fazer no teste de Pepino é checar e se posicionar contra seu banco de dados, seu usuário não pode realmente espreitar sob o capô de sua aplicação e olhar para o banco de dados inteiro para encontrar o que eles precisam, nem eles querem DIREITO. Usando Pepino e afirmando em saída html nos faz pensar como um usuário e nos obriga a garantir que nós fornecemos a experiência que eles querem e merecem.
Eu recentemente dei uma palestra para o Meteor Charlotte sobre este mesmo tópico, e eu gravei para que você possa me ver falando sobre isso e fazendo algum código ao vivo também. Espero que isso ajude você a começar!

Adaptador de interface do usuário do Ranorex.
Ao acompanhar elementos únicos da interface do usuário com o Ranorex Spy, o Ranorex tenta especificar o papel e a tecnologia do elemento. O Ranorex reconhece mais de 30 dos tipos mais usados ​​de elementos da interface do usuário. No vocabulário Ranorex, esses tipos são chamados de "adaptadores". Cada elemento individual mostrado dentro da árvore de elementos do Ranorex Spy pode ser acessado usando os adaptadores de UI do Ranorex que o elemento suporta. Se o Ranorex não puder atribuir um tipo de adaptador mais específico a um elemento da interface do usuário, ele será exibido como 'Desconhecido'.
Os adaptadores Ranorex fornecem mais conveniência ao criar testes automatizados. Aqui está um exemplo: Um adaptador de texto Ranorex fornece propriedades relacionadas à caixa de texto como 'Text' ou 'SelectionText'. Em comparação com um adaptador de texto simples, um adaptador TreeItem do Ranorex fornece propriedades e métodos específicos de itens de árvore, como expandir ou recolher. O Ranorex Spy mostra todas as propriedades relacionadas ao adaptador na guia 'Visão geral'.
Propriedades de um adaptador 'Text' Ranorex.
Propriedades de um adaptador 'TreeItem' Ranorex.
A seção 'Geral' no Ranorex Spy mostra as propriedades gerais que estão disponíveis para qualquer tipo de elemento da interface do usuário. Todas as outras informações na guia "Visão geral" estão relacionadas ao tipo de adaptador suportado pelo elemento.