Le buone pratiche di programmazione consigliano di inserire delle asserzioni nelle proprie classi, ma cosa succede quando poi testiamo il nostro codice con NUNIT? Il problema è che al fallimento di una asserzione il test mostra la classica messagebox di avvertimento e purtroppo l'esecuzione si ferma fino a che l'utente non interviene premendo un bottone.
La soluzione a questo problema è disabilitare i trace listener standard nel web.config del progetto NUNIT.
<trace autoflush="false" indentsize="4">
<listeners>
<clear/>
</listeners>
</trace>
</system.diagnostics>
In questo modo al fallimento di una asserzione i vostri test non si interromperanno. Se volete comunque vedere le asserzioni fallite è possibile utilizzare l'oggetto standard ConsoleTraceListener in questo modo.
<SetUp()> Public Sub Init()
If (Not Trace.Listeners.Contains(Listener)) Then
Trace.Listeners.Add(Listener)
End If
End Sub
In questo modo tutti i messaggi di trace standard del .NET, che comprendono anche i messaggi generati dal fallimento delle asserzioni standard, verranno ridirezionati nella console e sono quindi visibili nella GUI del nunit.
Purtroppo per ragioni a me sconosciute se si inserisce il ConsoleTraceListener dal web.config e non in maniera programmatica non funziona, mah....
Alk.
Alk.
Inoltre per blog principalmente tecnici quello che veramente è importante non è il layout o l'aspetto grafico ma il contenuto, penso che questo stile sia leggero e leggibile e non mi dispiace.
Prossimamente se ho tempo vedrò magari di mettere mano al css per capire se si può comunque formattare meglio il menu a sinistra che comunque mi pare troppo scarno.
Attendo commenti.
Alk.
Nello sviluppo di applicativi ASP.NET la possibilità di scomporre l'interfaccia utente in parti con l'uso degli user control è senza dubbio una caratteristica fondamedntale. Se si vuole rendere validabili i propri controlli con i validatori standard tipo un requiredFieldValidator è necessario decorare la classe che rappresenta lo user control con l'attributo ValidationPropertyAttribute che ha bisogno di un solo parametro contenente il nome della proprietà che contiene il testo da validare.
In pratica i validatori lato server recuperano dinamicamente il valore della proprietà indicata tramite il ValidationPropertyAttribute e la validano, ma solamente lato server. Per quanto riguarda il lato client è consigliabile leggersi questo articolo che parla in maniera abbastanza dettagliata dei validatori. Alla fine trovate scritto che
"For validation to work client-side as well, this property must correspond to the value attribute of the HTML element that gets rendered on the client. Many complex controls such as DataGrid and Calendar do not have a value on the client and can only be validated on the server. This is why only controls that correspond closely to HTML elements can be involved in validation. Also, a control must have a single logical value on the client. This is why RadioButtonList can be validated, but CheckBoxList cannot."
In pratica quindi per avere una validazione lato client è sicuramente necessario sporcarsi le mani con javascript custom.
Alk.
Back Next