Carey Brown wrote:^[a-zA-Z][a-zA-Z0-9_]{7,29}$
The first part of the expression handles the first character leaving 7 - 29 left to match.
Don't use the '+'
Tim Holloway wrote:No, Junit, at least, does NOT return anything from tests. If a test fails, it throws an Exception.
I can see where it might facilitate testing for the method UNDER test to return a result, but I don;'t recommend doing so, partly because sooner or later someone is likely to mis-use it in production.
Then again, going a "get" on a list doesn't normally cause UI effects, which is what the sample code seems to be expecting. At a minimum, I'd expect to see the list-management code in a separate method from the UI-affecting code and tested seperately. Even if a higher-level method wsa used to mutually invoke them.
Going to an even higher level, in Model/View/Controller terms, it gives me the impression that Model and Controller are both part of the same class and that's not really how MVC should be working. It's one reason why I take people to task when they call their JSF backing beans "Controllers". They aren't. They're Modes, which may have connexion to business logic, but their Controllers are located elsewhere.
Campbell Ritchie wrote:Welcome back
![]()
Do testing methods usually return a value? I may well be mistaken, but I would sooner stick to the void method and write another method to return a String.
Junilu Lacar wrote:You can also use a data table with word and URL in your test specification (the Gherkin part) -- this allows you to parameterize at the specification level instead of in the step definition as I showed earlier.
Bottom line, if you find yourself writing multiple conditionals in a test or step definition, then think about changing to a data-driven parameterized test instead.
Campbell Ritchie wrote:
Yes; it's good to see you back
Matthew Bendford wrote:Another common type of attack vector should also get mentioned: SQL injection.
It's pretty much the same idea: Unfortunately many beginner level tutorials, teachers and books commonly use simple string concatination to piece together sql queries. This works with provided sample data but already breaks on something common as a forum. The english language commonly uses both types of quote-marks: The single quote ' and the double quote ". If you now try to store this very line in a database one of them is used as delimiter character - and when encountered unexpected means end of input string which corrupts the sql query and the best case is an error returned from the database.
If you manipulate an input to a vulnerable qurry in a specific way you can get any sort of result from wiping the database over free access to leak its content.
So to get around this you have to sanitize the user input and properly build your query. One part of it is to use PreparedStatements. The query is done with placeholder characters (usually the question mark ?) and the values are filled with setters. This is also a way of type safety: If you expect a numerical value but you get a letter or other symbol the setter alrwady fail fast building the sql query before anything is ever send to the database.
An additional way of user input sanitization is limit the input characters. For a name there's a reason for a single dash - but a double dash -- (the sql comment marker to ignore the rest of the query srring) doesn't make sense. This can be a simple typo - but can also be an attacker trying to forge a bad query. You should reject such a name even before building the query as the input already looks too suspicious.
This list goes one for quite some lines. Atracker found all crazy issues over the decades like what's called a reverse shell abusing a bug in the apache web server or the recent log4j (which I became a victim of). The overall gist is: NEVER trust the user input. Always pre-check and validate and sanitize it and don't use simple string concatination if other methods are available like varargs methods for execute sub-processes, prepared statements for sql or simple I/O like a file by using a languages internal api rather then rely on a potential flawed shell command.