I want to automate some tests where I have to manipulate the system time to check for authentication behaviours of a program that is written in golang. According to this post, libfaketime does not work with golang. Is there another way that I can achieve what I want to do with libfaketime?
Here's a description of what libfaketime does from github.
libfaketime intercepts various system calls that programs use to retrieve the
current date and time. It then reports modified (faked) dates and times (as
specified by you, the user) to these programs. This means you can modify the
system time a program sees without having to change the time system-wide.
No, there is none.
You need to use something like clockwork (see this for more) and explicitly pass "time" implementation around your code.
Update from 2021-03-01 with a more up-to-date list of options:
https://github.com/LopatkinEvgeniy/clock
https://github.com/jonboulle/clockwork
https://github.com/benbjohnson/clock
https://github.com/facebookgo/clock
https://github.com/tkuchiki/faketime
https://github.com/rzajac/clock
There is this repository (tkuchiki/faketime) which claims to be able to fake the time.Now()-function. I don't know how extensively this works and haven't tested it. But it sounds like it might be a solution to your problem.
Related
Goal:
Determine if a functional test was successful.
Scenario:
We have a functional requirement: "A user should be able to signup with username and password. The username has to be a valid email-adress. The password has to be at least 8 characters long".
We have a method "SignupResult UserManager.Signup(string username, string password)".
We want a happy-test with valid intputs, and a sad-test with invalid inputs.
Sub-Systems of the UserManager (e.g. Database) can be either mocked or real systems.
Question:
What would be the best way to determine if the user was successfully signed up. I can imagine the following options:
If any of the sub-system was mocked, one could check if a specific function like "DB.SaveUser(...)" was called. This would destroy the idea of a functional test being a blackbox test and requires that the test-writer has knowledge of the implementation.
If we use real sub-systems, one could for example check if the row in the DB exists. That would be not adequate like the attempt above.
One could use another function like "UserManager.CheckUser(...)" to check if the user was created. This would introduce another method that is tested, also there may be operations that would have no "test-counterpart", or one would have to implement them, just for testing - that seems not ideal.
We could check the result "SignupResult" and/or check for exceptions thrown. This would require defining the interface of the method. This also would require all methods to return a sensible value - I guess this will be a good approach anyway.
To me the last methods seems to be the way to go. Am I correct? Are there other approaches? How would we check side-effects like "an email was sent to the new user" ?
You may want to acquaint yourself with the concept of the Test Pyramid.
There's no single correct way to design and implement automated tests - only trade-offs.
If you absolutely must avoid any sort of knowledge of implementation details, there's really only way to go about it: test the actual system.
The problem with that is that automated tests tend to leave behind a trail of persistent state changes. For example, I once did something like what you're asking about and wrote a series of automated tests that used the actual system (a REST API) to sign up new users.
The operations people soon asked me to turn that system off, even though it only generated a small fraction of actual users.
You might think that the next-best thing would be a full systems test against some staging or test environment. Yes, but then you have to take it on faith that this environment sufficiently mirrors the actual production environment. How can you know that? By knowing something about implementation details. I don't see how you can avoid that.
If you accept that it's okay to know a little about implementation details, then it quickly becomes a question of how much knowledge is acceptable.
The experience behind the test pyramid is that unit tests are much easier to write and maintain than integration tests, which are again easier to write and maintain than systems tests.
I usually find that the sweet spot for these kinds of tests are self-hosted state-based tests where only the actual system dependencies such as databases or email servers are replaced with Fakes (not Mocks).
Perhaps it is the requirement that needs further refinement.
For instance, what precisely would your user do to verify if she has signed up correctly? How would she know? I imagine she'd look at the response from the system: "account successfully created". Then she'd only know that the system posts a message in response to that valid creation attempt.
Testing for the posted message is actionable, just having a created account is not. This is acceptable as a more specific test, at a lower test level.
So think about why exactly users should register? Just to see response? How about the requirement:
When a user signs up with a valid username and a valid password, then she should be able to successfully log into the system using the combination of that username and password.
Then one can add a definition of a successful login, just like the definitions of validity of the username and password.
This is actionable, without knowing specifics about internals. It should be acceptable as far as system integration tests go.
I always perform regression testing as soon as the changes come up. The case is the client comes up with changes or additional requirement every now and then and that makes the case more messy. I test something and then the whole things get changed. Again I have to test the changed module and perform integration testing with other modules that is linked with it.
How to deal with such cases?
1) 1st ask complete Clint requirement and note every small point in doc.
2) Understand that total functionality.
3) Use your default testing method.
4) Your not mention which type your testing.( app or portal )
5) As well as possible which is comfortable and feel easy you continue that testing.
6) You want automation testing.please use this (App-appium or Web-selenium)
I hope this is helpful for you.
I would suggest you the following things
->Initially gather all the requirements and check with the client if you have any queries through email.
->Document every thing in MOM whenever you have client call and share with everyone who has attended the call(dev team,client,business,QA)
->Prepare a Test Plan strategy document, test cases and share it to client and request him for his sign off.
->Once, you are all set start with smoke testing then check the major functionalities in that release and then could proceed further.
->You could automate the regression test cases as you are going to execute them for every release(I would suggest to use Selenium if its a desktop application then UFT).
Kindly, let me know if you have any queries.
I made a program that gets the data from the clipboard and saves it in a string variable. Then it looks for specific words in that string and generates several URLs. Afterwards it open the browser and shows each URL in an own tab.
Some of my friends already use this program frequently and I want to have some statistics about how often. I simple counter variable would be enough but I need to get access to it.
I came up with two options that could work:
I could send an email to a specific adress every time my app is executed. Then I can track the amount of uses by manually or automaticly counting the amount of emails in the postbox. I think this would be a Vers dirty solution.
I could create and publish a website containing a counter. This counter could be refreshed by my application. This solution is a bit better I think but a lot more work for just one single counter.
Do you have better ideas to solve my problem or is one of mine already a good one?
Thank you in advace!
You can use Measurement Protocol Overview. This provides you statistics of usage your application compared with Google Analytics. You can see even a geo statistic, version distribution, crash reports. It is easy to use it from .net. It is just about requesting http request to google.
I'm looking for the way to restrict users access by time in my grails application. I mean that users will be able to use (not only login) application only in allowed timeframes defined by days of week and start & end hours.
Could anyone advise the best way of doing this?
I'm thinking about adding some set of tables to my domain model which will contain time access rules. This rules will be applied to roles and users. Users rules will override roles rules.
As I understand, I need to implement some Authorization (not Authentication) Filter, which will do the check of time restrictions.
Am I one the right way? If so, then could anyone provide some usefull links for this task?
Aha, I already answered this on the mailinglist.
What I wrote:
Possible solution (two-fold):
For login:
Custom UserDetails class that throws appropiate exception if outside
timeslot (not sure if it is the most semantically correct place to do
it, but it's easy there).
For people already logged in:
Quartz job that run at the boundaries (like 2pm if thats when a slot
ends) that run through active sessions and invalidate them.
You can keep a list of active sessions in various ways, one (one and a
half really, not sure if you can use Burt's plugin in a programmatic
way) are covered here:
In grails, how do I get a reference to all current sessions?
I see now that the AccessDecisionVoter is a better solution than the custom userdetails, but the answer still remains for the same for the already logged in people.
I would like Jalopy to format my return and throw statements such that they look like a method call since they are:
return(true);
throw(new IllegalArgumentException("You can't do that, what we you thinking?"));
I have the rest of the code formatted exactly the way I want so this is the icing on the cake.
Also as an aside, I work on a project with a few team members and each have our own preference for looking at code, has anyone setup Jalopy in conjuction with a successful build as well as checkout?
So, when I checkout code, it gets formatted to my liking, and then each time I get a successful build, it gets formatted according to the Java/Sun Standard and then checked in?
Walter
I would like Jalopy to format my return and throw statements such that they look like a method call
I didn't find anything about this in Jalopy's Manual and think this would require extending Jalopy.
(...) when I checkout code, it gets formatted to my liking, and then each time I get a successful build, it gets formatted according to the Java/Sun Standard and then checked in?
If you are using subversion, maybe you could use a client-side hook on checkout and a pre-commit hook on commit.
The commercial Jalopy supports this.
Here are the links for the corresponding user's guide sections:
Insert throws parentheses