As opniões contidas neste blog são as minhas próprias opniões e não representam de maneira alguma as opniões do meu empregador.
no primeiro dia do teched 2011, eu e meu amigo fábio fizemos uma quick session mostrando um pouco como podemos melhorar um código. a idéia era mostrar alguns princípios importantes que o desenvolvedor deve ter em mente quando está escrevendo o seu código. mostramos a importância darmos bom nomes de variáveis, reduzir a duplicidade de código, extração de métodos e divisão de responsabilidade. estes fatores e alguns outros contribuem para legibilidade, manutenção e reduz a complexidade ciclomática.
na nossa apresentação usamos um código de validação de cpf de quase 100 linhas para um código de cerca de 10 linhas. é claro que todo o código não sumiu. foi direcionado para outros métodos. mas desta maneira o código ficou bem mais legível e de fácil manutenção. Além disto, a complexidade ciclomática de 20 no primeiro momento foi reduzida para 4. vale mencionar que o código é uma pequena alteração de um código dos muitos códigos que encontramos na internet. isto mostra que não é tão difícil você se deparar com um código com as mesmas oportunidades de aprimoramento.
o código disponiblizado tem 4 projetos em c#. o projeto “CpfVerification” é o projeto principal e contém a classe “CpfVerification”. o projeto “CpfVerificationTests” contém 2 unit test. um positivo e outro negativo. é claro que caberiam muito mais testes unitários. entretanto, como este não era o objetivo desta palestra, colocamos apenas 2 testes que nos davam a confiança para fazermos as refatorações necessárias. acredito que isto irá ajudar vocês também.
o projeto “CpfSteps” contém 7 classes. uma para cada estágio das alterações que fizemos. estas classes estão numeradas de 1 a 7 no final do nome. sendo a 1 o estado inicial do código e 7 o estado final. o projeto “cpfTestSteps” contém duas classes de testes unitários. a primeira é o estado inicial dos testes. a classe que terminar com “CpfType” contém a conversão dos testes unitários para o uso de tipo CPF. isto suporta uma das grandes mudanças deste método para dividir as responsabilidades.
é claro que este método poderia ser ainda melhor. a classe cpf poderia ser preparada para não usar mais uma string. e não queremos dizer que esta versão final é a melhor versão. mas o que gostaríamos de mostrar é como aquele código existente poderia ser melhor se algumas boas práticas fossem aplicadas.
convidamos vocês a baixarem o código e tentarem vocês mesmo fazerem a refatoração. os testes unitários ajudam vocês a garantirem que o código continua funcionando como esperado. se quiserem, podem nos enviar suas versões finais e trocamos uma idéia sobre o resultado.
[]s
amanhã eu e meu amigo fábio vazquez estaremos apresentando uma quick session no teched 2011.
o tema da session é Melhorando o seu código!. você pode ver a descrição abaixo. como será uma quick session, não terá ppt e sim muita demo. vamos pegar um código "ruim" e vamos melhorá-lo.
se quiser assistir, será as 16:10.
QS16 | Melhorando o seu código!Código limpo, de fácil manutenção! Este é o sonho de todos os desenvolvedores e times. Porém, a prática não parece ser tão simples. Esta palestra partirá de um código eficaz, que atinge o objetivo para que foi escrito, porém não tão limpo, de fácil manutenção e eficiente. De maneira prática, usando conceitos de “clean code” e “refatoração” e boas práticas, tornará este código mais eficiente, considerando princípios, métricas e estilos.
ontem foram feitos alguns anúncios interessantes a respeito da nova versão do windows, com o codinome “windows 8”. foi anunciada a data do próximo evento de desenvolvedores. como já havia mencionado aqui, o save the date era para 13 a 16 de setembro de 2011. agora o evento foi confirmado. acontecerá na california e terá o nome de BUILD windows. este evento promete mostrar que o windows 8 mudará tudo, assim como, o windows 95 mudou o pc naquela época.
além disto, foi divulgado um vídeo, que você poder ver aqui embaixo, mostrando um pouco de como deverá ser a experiência do usuário nesta próxima versão. vale muito a pena ver. quem disse que a microsoft não inova mais?
você deve concordar comigo que usar bem a ferramenta de debug é fundamental para um bom desenvolvedor. o que eu costumo ver é o dev afirmar que sabe usar o debug, mas depois ficar horas a fio tentando adivinhar o que passa pelo seu código e não consegue ver os sinais claros do problema apresentado nas várias janelas disponíveis ao debugar.
um problema clássico que eu vejo é quando o arquivo de extensão pdb, obrigatório para o debug, está em uma pasta diferente do assembly. o caso mais comum disto acontecer é quando você quer continuar o debug em uma dll que está no gac. você aperta o F11, mas o debug parece apenas ignorar o seu comando e ir para a próxima linha. isto acontece porque apenas a dll está no gac. o arquivo de símbolos (pdb) não é encontrado. e como consequência, o debug não pode ser feito.
neste vídeo eu vou mostrar como você pode identificar quando o arquivo de símbolos foi carregado ou não. e como você pode carregá-lo de um outro lugar.
esta pergunta é muito frequente. o quanto deve se automatizado? quais testes automatizar? trabalhando há alguns anos com testes, posso dizer que não é fácil responder esta pergunta.
há quem diga que todos os testes devem ser automatizados. normalmente esta é meta e o desejo de todos que começam a testar. também já pensei assim...doce sonho. pior, há quem diga que se você não automatiza 100%, não está fazendo direito.
também há aqueles que dizem que nada deve ser automatizado. que todos os testes devem ser manuais. será!?
recentemente recebi o link deste post de um amigo. gostei bastante da resposta dele a esta pergunta:
“você deve automatizar 100% dos testes que devem ser automatizados”
excelente resposta. vale a pena ler o artigo e entender o que o ajuda a decidir o que deve ser automatizado. não preciso dizer que concordo com a linha de raciocínio dele.
se você é um desenvolvedor ligado, você já viu alguma coisa sobre o azure e provavelmente tem bem claro na usa mente qual a vantagem de desenvolver sua aplicação usando este plataforma.
o interessante é poder usar todos estes benefícios não apenas para as aplicações web e para os clientes desktop que acessam os serviços. é muito interessante poder usar estes recursos e serviços em qualquer plataforma.
e os devices móveis são as sensações do momento. praticamente todas as aplicações tem disponibilizado suas versões móveis.
hoje foi anunciado o Windows Azure Toolkits for Devices. este toolkit simplifica a complexidade de suportar múltiplas plataformas. nesta primeira versão está incluído o windows phone, iOs (iphone e ipad) e um preview da ferramenta para android.
também foram disponibilizados screencasts e posts demonstrando como usá-lo.
no dia 11 de maio ocorrerá o evento de lançamento da versão retail do dynamics ax aqui no brasil. se você tem interesse em participar veja os detalhes aqui.
no início deste mês, no dia 2 de maio, foi liberada a versão R2 do dynamics ax for retail. a novidade legal é o suporte para as impressoras fiscais entretanto este release não contém o suporte para PAF-ECF. então esta versão vale para os estados que não exigem o certificado PAF-ECF.
durante o mix foi anunciada a data do próximo professional developer conference, mais conhecido como pdc.
portanto, anote na sua agenda as datas do pdc 11: 13 a 16 de setembro de 2011.
na semana passada foi realizado em atlanta, nos estados unidos, o convergence. o convergence é o grande evento realizado pela ms para dynamics. eu poderia dizer que o convergence está para dynamics, como o que o teched está para o pessoal de infra, o pdc para os desenvolvedores e o mix para o pessoal de web.
durante este evento foi mostrado o dynamics ax 2012. versão que eu tive o prazer de ter participado do desenvolvimento. a versão está bem legal mesmo!!
se você quiser ver o keynote feito pelo steve ballmer e pelo kirill tatarinov (vp do microsoft business solutions), acesse aqui.
hoje terminou o mix 11. como vocês devem saber, este é o evento da ms que mais me chama a atenção nos últimos anos.
infelizmente só pude acompanhar os keynotes pela transmissão pela internet e não pessoalmente. mas, não posso deixar de colocar as minhas impressões.
não resta dúvida que o ponto alto dos keynotes foram: html5 e IE (internet explorer) e o kinect. e também o “mango”, a próxima versão do windows phone.
o desempenho do html 5 no IE 9 é realmente interessante. o uso dos aceleradores gráficos faz uma diferença significativa. e claro, a primeira demo do IE 10. se o IE9 já dá um banho nos concorrentes quando se trata de html 5, dá para imaginar o que o IE 10 vai fazer. e olha que esta foi só a primeira demo. na minha opinião, o ponto alto foi a demo comparando com o chrome. também foi demonstrado o maior pacman do mundo. este foi criado por um parceiro para demonstrar como IE está realmente a frente dos concorrentes em relação a html 5. não dá para deixar de citar também o html 5 labs.
sou forçado a concordar com um amigo que, já há 2 anos atrás, dizia que o html 5 iria dominar e deixar para trás qualquer tecnologia web que requer plugin.
o ponto mais alto para mim foram as demos do sdk do kinect para windows. parece que será muito simples usar este extraordinário “device”. as demos além de mostrarem a facilidade de criar aplicações usando o kinect, também foram divertidas. não vejo a hora do sdk estar disponível para download e começar a me divertir.
também foi demonstrado o “mango”, a próxima versão do windows phone. não há como negar que o time tem se esforçado para rapidamente melhorar cada vez mais o windows phone. foram mostrados as melhorias relacionadas a performance e usabilidade. também algumas melhorias relacionadas a busca (“search”). com apenas uma linha de código é possível fazer buscas e deixar o trabalho por conta do banco de dados.
ah!! foi anunciado o lançamento do angry birds para windows phone em maio. :) vamos ver como a comunidade de desenvolvedores de aplicações móveis vão reagir a estas melhorias.
ainda foi mostrado a nova versão do webmatrix. achei bem legal. fácil criar websites pessoais. as melhorias da “ide” também foram bem legais.
também falou-se a respeito de azure e silverlight 5.
minhas impressões finais são: html 5 veio para ficar sem dúvidas nenhuma. e o investimento para que estejamos a frente está sendo e continuará a ser grande. as tecnologias dependentes de plugin que se cuidem.
o kinect vai arrebentar ainda mais. a reação dos desenvolvedores ao sdk para windows é a melhor possível. acredito que teremos rapidamente diversas aplicações usando as mãos. se isto não é ser inovador, eu não tenho idéia do que é!!!
o gartner disse que o windows phone estará entre os 2 smartphones mais usados em 2015. resta saber ser eles acertarão que fará companhia a ele, iphone ou android. :)
os vídeos dos keynotes e das sessões já podem ser vistos aqui.
tem bastante material interessante para aprender mais sobre windows azure. entre este materias estão exemplos de código, alguns vídeos e também hands-on-labs, que são laboratórios passo-a-passo.
então se você quer aprender um pouco sobre windows azure, acesse ao material disponível no site do windows azure. existe também material em português aqui.
o mix 11 acabou de começar. se você quiser pode assistir o keynote ao vivo aqui.
estou colocando os pontos altos no meu twitter. se quiser acompanhar: http://twitter.com/#!/cezargBr
estão abertas as inscrições para o mix 11, que será dos dias 12 a 14 de abril de 2011, em las vegas (é claro!). também se pode votar em algumas sessões.
o mix é um evento voltado para os profissionais de web, desenvolvedores, designers e “ux” (user experience). o evento foi marcado nos últimos anos por lançamentos ou acontecimentos interessantes. por exemplo, silverlight 2, quando foi anunciado o .net no browser e a entrevista do steve balmer pelo guy kawasaki.
eu já estive em uma das edições e posso dizer que valeu a pena. se não puder estar presente, pelo menos, fique ligado para acompanhar as palestras que são gravadas.
é interessante como a internet, blogs e tweets conseguem movimentar certos assuntos e fazer que eles tomem proporções enormes.
um dos assuntos que está sendo recorrente e gerando muitas conversas e opiniões nos últimos dias é sobre o movimento de “software craftsmanship”.
um post que está gerando uma grande movimentação de comentários foi do dan north. o título é “programming is not a craft”. em português seria “programação não é um ofício”.
só pelo título você já deve conseguir imaginar o burburinho que ele está gerando. ele aborda que o valor do software está no que ele oferece ao usuário, independente de quão feio ou bagunçado é o código. que somente desenvolvedores apreciam código bonito. isto é uma verdade. para o usuário final o que importa é realmente se o software atende as suas necessidades.
ele também demonstra o receio, de que de alguma maneira, o movimento de “software craftsmanship” faça que o código seja mais importante que a necessidade do cliente.
“Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines. Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work. (Although it’s fair to say they appreciate decent boiler controls.) … The thing is, at one level software can be described by the utility it provides. It doesn’t matter how ugly it is under the hood as long as it delivers the goods. A programmer can show beautiful software to another programmer, but that’s where the appreciation stops for software per se.” – Dan North
mas parece que dan north 1) desconsidera os benefícios de um código bem escrito. que o código muito provavelmente 2) precisará de manutenção. que o mesmo usuário satisfeito ao usar o software 3) pensará e desejará novas funcionalidades. e que dependendo do código, estas novas funcionalidades podem levar muito tempo para serem entregues. e que dependendo do código talvez elas nem funcionem direito (em alguns casos nunca funcionarão direito).
o fato do movimento de “software craftsmanship” incentivar o ofício em nenhum sentido ou momento quer dizer que a necessidade do cliente deve ser colocada em segundo plano.
jason gorman fez um excelente post – “Why Software Craftsmanship Is Not Just About "Beautiful Code". não sei se era uma reposta direta ao dan north. mas se não for, bem que poderia ser.
jason destaca que o “software craftsmanship” é sobre construir a coisa certa, ou esperada pelo cliente, mas da maneira certa. o resumo de quão bem ele demonstra como o pensamento de dan north está errado é o trecho abaixo.
“Do programmers who dedicate themselves to improving in the technical practices (because programming is a technical practice, in case you were wondering) tend to be blinded to the customer's needs? To me, that sounds like "musicians who strive to perfect their chops don't play with feeling". And there's absolutely no evidence of that.” – Jason Gorman
“Do programmers who dedicate themselves to improving in the technical practices (because programming is a technical practice, in case you were wondering) tend to be blinded to the customer's needs?
To me, that sounds like "musicians who strive to perfect their chops don't play with feeling". And there's absolutely no evidence of that.” – Jason Gorman
um segundo ponto é que ele mostra como um desenvolvedor que não melhora suas competências e habilidades tendem a desagradar seu clientes mais facilmente.
“What's certainly true is that programmers who don't strive to improve at programming tend to dissatisfy customers by delivering software that is unreliable and expensive to change, regardless of what it does. Sure, the customer may be delighted with the first release - hooray for our side - but considerably less delighted when the bug reports start flooding in and we have to tell them how long a second release is going to take. Because, you see, all those horrendous legacy systems we end up waist-deep in were once bad jobs of something useful. By delivering buggy, unmaintainable software that the customer could use, we effectively hung a millstone around their necks, and we know from experience that the pain comes sooner than we think.” – Jason Gorman
“What's certainly true is that programmers who don't strive to improve at programming tend to dissatisfy customers by delivering software that is unreliable and expensive to change, regardless of what it does. Sure, the customer may be delighted with the first release - hooray for our side - but considerably less delighted when the bug reports start flooding in and we have to tell them how long a second release is going to take.
Because, you see, all those horrendous legacy systems we end up waist-deep in were once bad jobs of something useful. By delivering buggy, unmaintainable software that the customer could use, we effectively hung a millstone around their necks, and we know from experience that the pain comes sooner than we think.” – Jason Gorman
O que é legal e importante, como comentei no post do dan, é atendermos as necessidades do cliente, mas o mesmo tempo, tratarmos o software como um ofício.
o que você acha? o software é ou não um ofício?
já teve que mexer em um código que você está vendo pela primeira vez? muito provavelmente sim. então você vai entender do que eu vou falar.
a primeira coisa que eu faço quando preciso mexer em um código pela primeira vez é ler o código. o meu objetivo é entender o que ele faz. a segunda é identificar o que precisa ser alterado ou incluído. enfim, a terceira é codificar a alteração.
infelizmente todas estes passos se tornam muito mais complicados e dolorosos porque a pessoa que escreveu aquele código tinha tudo na cabeça e tinha preguiça de escrever. além disso, devia estar doido para ver logo o resultado do trabalho. então ele tenta codificar o mais rápido possível, teclando o menos possível. qual o resultado?
os nomes das variáveis são os piores possíveis e os menores possíveis. embora a pessoa que escreveu tinha tudo na mente, quem mexer neste código depois vai ter muito mais trabalho para: 1. entender o que o código faz, 2. identificar o que precisa ser alterado e 3. codificar a alteração.
recentemente eu comecei a ler um código onde a primeira linha era a que está abaixo. o que você acha que eu podia esperar das próximas linhas!!?? :(
1: public void MetodoQualquer()
2: {
3: int i, j, y, k, w;
algumas vezes acompanhei pessoas escreverem código usando estas variáveis “mágicas”. algumas vezes em entrevistas outras vezes fazendo “pair programming”. o que acontece na maioria das vezes é que o próprio desenvolvedor se confunde ao usá-las. imagine então quem for ler este código depois.
nunca devemos subestimar o valor de bons nomes de variáveis.
parte do problema começa nas escolas técnicas ou faculdades. é comum vermos os professores usarem estas variáveis mágicas em pequenos exemplos. recentemente eu estava ajudando um rapaz que faz um curso técnico. ele me mostrou o código de um trabalho dele. o código estava correto, mas cheio destas variáveis mágicas. e o professor dele aceitou e não fez nenhuma observação. e provavelmente será assim pelo resto do curso.
já participou de algum projeto ou trabalhou em alguma empresa que costuma rodar ou executar os testes em ambiente de produção? provavelmente sim. isto é muito mais comum do que muitos imaginam. quando prestava consultoria na minha própria empresa, participei de vários projetos em empresas grandes e importantes que forneciam apenas o ambiente de produção deles para realizarmos os testes que precisávamos antes da nova funcionalidade entrar em produção.
um segundo problema são os dados de testes comuns. como as palavras “teste” ou “test, “xxxx”. Ou números como “11111”, “99999” ou “12345”. normalmente estes dados são usados em campos que não estão sendo alvo dos testes. e normalmente é mais simples usarmos estas palavras ou números simples e comuns. Porém, esta escolha, por incrível que parece, pode potencializar ou criar problemas quando usado em testes no ambiente de produção.
james bach publicou uma história real, que aconteceu com ele mesmo, em seu blog. a história chega a ser engraçada. e serve muito bem para mostrar como é perigoso fazer testes em ambiente de produção e usar dados comuns. vou fazer um resumo da historia porque você pode ler os detalhes no seu blog.
como a maioria já deve ter visto em filmes, nos estados unidos é possível ter uma placa oficial de carro e personalizada. o james tem uma que é “tester”. recentemente ele recebeu uma multa por estacionamento proibido em um local perto da sua casa porém, que ele nunca estacionou. a multa era para a placa “tester”. ele verificou que era uma multa real, mas notou que a numeração do registro era esquisita, uma seqüência de números um (1). ele entrou em contato com o call center e explicou que poderia ser um erro. como ele é um tester imaginou que poderia ser resultado um teste feito em ambiente de produção e sugeriu isto.
como resultado do chamado dele, ficou confirmado que a multa estava errada e que o lançamento era resultado de um teste feito em ambiente de produção,eles estavam testando a integração com um novo sistema. o registro não havia sido apagado depois do teste. ele inclusive mostra a carta que recebeu.
portanto, na próxima vez que tiver que realizar testes em ambiente de produção, use este exemplo com o seu cliente ou gerente para mostrar como é realmente uma péssima idéia usar este ambiente para teste. se mesmo assim não houver outra opção, pense bem no risco que você pode estar adicionando. pense e crie calmamente um check-list de tudo que precisa ser alterado ou revertido ao final do processo. evite usar números ou nomes que podem estar relacionados a nomes ou registros existentes.
P.S: cheguei a este post através de um tweet de @dhemery
muito se fala sobre tdd (test driven development). qualquer um que já tentou fazer na prática sabe que embora a teoria seja simples e baseada nos passos: red, green, refactor (vermelho, verde, refatoração), quando se começa a praticá-lo muitas dúvidas surgem.
por exemplo, a medida que se evoluiu a prática de tdd afirmou-se que o “teste tem que se tornar mais específico para que o código se torne mais genérico.” muitos vão dizer que não: tdd é fácil e resolve todos os seus problemas. para eles basta seguir os passos acima e tudo se resolve. para mim estes fazem parte do grupo que mencionei aqui. este post é para os que acreditam que dúvidas existem e que cometemos erros quando começamos a fazer tdd.
entre as dúvidas ou erros comuns (e eu os enfrentei :)) estão: como saber até onde ir com os testes unitários, como fazer que os testes sejam específicos a medida que evolui o código para se tornar genérico. como escolher os testes corretos.
o primeiro ponto para ter em mente é que a prática é que aperfeiçoa. então quanto mais praticar, e errar, mais se aprende.
porém, aprender com quem tem mais experiência também ajuda bastante. eu tenho um amigo com bastante experiência em tdd que eu sempre recorro em busca de ajuda. e recentemente um post do “uncle bob” me chamou atenção. ele faz uma transcrição de uma conversa entre dois devs sendo um praticando tdd e o outro ajudando. ele foca principalmente na questão do teste ser específico para que o código se torne genérico. mas dá para tirar lições interessantes sobre diversos aspectos de tdd.
o ponto é: tdd é muito legal, porém não é tão simples como parece fazer corretamente. mas a prática é a melhor maneira de se aperfeiçoar.
falar sobre “clean code”, bom design de código, boas práticas é “fácil”. os conceitos não são complexos e os benefícios são facilmente perceptíveis.
mas quando produzimos, nós e o nosso time, produz muito código nem sempre é fácil manter o código limpo e que os padrões esperados foram seguidos. a revisão de código feita por outros membros da equipe, o “code review”, ajuda bastante mas não é infalível.
neste ponto ter uma ferramenta para analisar o código é de grande ajuda. é aqui que entra o ndepend.
através dele você pode definir regras (as comuns e óbvias já estão definidas) e analisar o seu código com base nelas. o resultado pode ser visto num, ou em vários, relatórios.
o mais interessante é que agora ele é integrado ao vs2010 e você ver as violações a medida que desenvolve o seu código.
o beta do sp 1 para visual studio 2010 já está disponível para quem tem o msdn subscription. para os que não o msdn subscription poderão baixar o sp 1 aqui a partir de quinta-feira, dia 9 de dezembro de 2010.
se quiser saber mais sobre o sp1 de uma lida neste post e neste aqui também.
ontem no keynote do silverlight firestarter foi anunciado o silverlight 5 que está previsto para o ano que vem. entre as novidades desta nova versão estão mais algumas melhorias relacionado a mídia e streaming: suporte a “hardware vídeo decode” utilizando a GPU, suporte a alterar a velocidade do conteúdo de mídia no cliente com a correção do áudio automática e suporte a controle remoto.
outra melhorias estão relacionadas ao databinding que suporta breakpoints, suporte para gráficos de maneira que possam usar GPU e aceleradores gráficos.
o modo “out of browser” suportará múltiplas janelas (child windows) e permitirá que aplicações autorizadas tenham mais vantagens fora do “sandbox”.
e também ele suportará x64, obviamente para browsers x64.
e claro que como engenheiro de testes não poderia de mencionar o suporte a testes automatizados pela UI. a única coisa que não gostei da demo do john papa é que ele só destacou a funcionalidade de gravar os testes para gerar o código e não deu ênfase que os testes podem ser codificados diretamente, o que seria melhor (mas este não é momento para discutir isto :) ).
se você não assisitiu ao keynote ou as outras palestras pode dar uma olhada aqui.
continuo impressionado com a capacidade deste time de fazer releases em tão pouco tempo. parece que foi ontem que estava no mix 2007 vendo o mesmo scott guthrie falar do alpha do silverlight 2 com .net.
amanhã, ou melhor hoje, já passou da meia-noite, ocorre o “silverlight firestarter”. uma mistura de evento e treinamento com os feras do silverlight e keynote do scott guthrie. o evento será on-line. então se você se interessa por silverlight deveria se inscrever.
o windows completou 25 anos. para os que gostam de tecnologia é sempre legal ver um pouco do passado e como as coisas evoluiram. então, decidi colocar alguns vídeos que eu gosto aqui embaixo. o que acho legal é o que é mostrado como novidade, os gráficos, os jogos. também tem algumas reportagens legais como alguns brasileiros na microsoft na década de 90 e com o bill gates. também é legal ver como eram as coisas apenas 15 anos atrás. o pior é que vi muito destas coisas…to ficando velho.
como um engenheiro de teste é claro que vou dizer que teste é importante. e todo bom engenheiro de software sabe disto. e quando falo de teste não estou falando de teste de desenvolvedor ou teste unitário. estou falando sobre código escrito para verificar a qualidade de um produto.
o recente feature pack para visual studio 2010 fornece mais uma alternativa para teste de aplicações usando silverlight 4. aos poucos as alternativas para testes, unitários e não unitários, tem aumentado. com este feature pack é possível criar os seus testes de sistema, através da interface do usuário, usando codificação, e não apenas gravando o teste.
quem já criou testes conhece as limitações e “issues” de testes através da interface. entretanto o teste através da interface tem o seu valor. além disto, antes um conjunto de testes automatizados através da UI do que nenhum teste.
para usar este feature pack é necessário ter o vs ultimate, premium ou test professional.
nos meses anteriores minha atividade neste blog foi bem baixa. isto porque estava bem envolvido no rollup 6 do dynamics ax 2009.
então, embora atrasado, não poderia deixar de falar sobre o release do rollup 6. ele não traz grandes novidades para o brasil. mas, eu estive trabalhando na localização da nota fiscal eletrônica do méxico. é muito bom ver o resultado final de um ciclo de desenvolvimento.
se você está no brasil, o rollup 6 inclui o conteúdo de todos os rollups anteriores.
para mais detalhes, acesse o “knowledge base”.